早在Linux 2.2SIGSYS, SIGXCPU, SIGXFSZ和SIGBUS（非sparc和mips架构）的默认操作就是终止进程（但是不产生coredump）
在一些unix系统中SIGXCPU和SIGXFSZ信号是用来终止进程的，也是不产生coredunp，从Linux 2.4开始这些信号会产生coredump了。
标准信号-其它信号
Signal Value Action Comment
--------------------------------------------------------------------
SIGIOT 6 Core IOT trap. A synonym for SIGABRT
SIGEMT 7,-,7 Term
SIGSTKFLT -,16,- Term Stack fault on coprocessor (unused)
SIGIO 23,29,22 Term I/O now possible (4.2BSD)
SIGCLD -,-,18 Ign A synonym for SIGCHLD
SIGPWR 29,30,19 Term Power failure (System V)
SIGINFO 29,-,- A synonym for SIGPWR
SIGLOST -,-,- Term File lock lost
SIGWINCH 28,28,20 Ign Window resize signal (4.3BSD, Sun)
SIGUNUSED -,31,- Term Unused signal (will be SIGSYS)
信号29是在alpha中是 SIGINFO或SIGPWR，但是在sparc中是SIGLOST。
SIGEMT没有在POSIX.1-2001中定义, 但是在大多数Unix戏中是没有的，他的默认处理方式是coredump并且终止进程。
SIGPWR（没有在POSIX.1-2001中定义）他的默认处理方式是忽略。
SIGIO（没有在POSIX.1-2001中定义）在一些Unix系统中的处理方式也是忽略。
kill pid的作用是向进程号为pid的进程发送SIGTERM（这是kill默认发送的信号），该信号是一个结束进程的信号且可以被应用程序捕获。若应用程序没有捕获并响应该信号的逻辑代码，则该信号的默认动作是kill掉进程。这是终止指定进程的推荐做法。
kill -9 pid则是向进程号为pid的进程发送SIGKILL（该信号的编号为9），从本文上面的说明可知，SIGKILL既不能被应用程序捕获，也不能被阻塞或忽略，其动作是立即结束指定进程。通俗地说，应用程序根本无法“感知”SIGKILL信号，它在完全无准备的情况下，就被收到SIGKILL信号的操作系统给干掉了，显然，在这种“暴力”情况下，应用程序完全没有释放当前占用资源的机会。事实上，SIGKILL信号是直接发给init进程的，它收到该信号后，负责终止pid指定的进程。在某些情况下（如进程已经hang死，无法响应正常信号），就可以使用kill -9来结束进程。
若通过kill结束的进程是一个创建过子进程的父进程，则其子进程就会成为孤儿进程（Orphan Process），这种情况下，子进程的退出状态就不能再被应用进程捕获（因为作为父进程的应用程序已经不存在了），不过应该不会对整个linux系统产生什么不利影响。
Go中的信号发送和处理
有时候我们想在Go程序中处理Signal信号，比如收到 SIGTERM 信号后优雅的关闭程序(参看下一节的应用)。Go信号通知机制可以通过往一个channel中发送 os.Signal 实现。首先我们创建一个
