Quartz 4

进程信号

8 min read

信号类型

Linux系统共定义了64种信号，分为两大类：可靠信号与不可靠信号，前32种信号为不可靠信号，后32种为可靠信号。

  • 不可靠信号： 也称为非实时信号，不支持排队，信号可能会丢失, 比如发送多次相同的信号, 进程只能收到一次. 信号值取值区间为1~31；

  • 可靠信号：也称为实时信号，支持排队, 信号不会丢失, 发多少次, 就可以收到多少次. 信号值取值区间为32~64

$ kill -l
HUP INT QUIT ILL TRAP IOT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH POLL PWR SYS
取值名称解释默认动作
1SIGHUP挂起
2SIGINT中断
3SIGQUIT退出
4SIGILL非法指令
5SIGTRAP断点或陷阱指令
6SIGABRTabort发出的信号
7SIGBUS非法内存访问
8SIGFPE浮点异常
9SIGKILLkill信号不能被忽略、处理和阻塞
10SIGUSR1用户信号1
11SIGSEGV无效内存访问
12SIGUSR2用户信号2
13SIGPIPE管道破损，没有读端的管道写数据
14SIGALRMalarm发出的信号
15SIGTERM终止信号
16SIGSTKFLT栈溢出
17SIGCHLD子进程退出默认忽略
18SIGCONT进程继续
19SIGSTOP进程停止不能被忽略、处理和阻塞
20SIGTSTP进程停止
21SIGTTIN进程停止，后台进程从终端读数据时
22SIGTTOU进程停止，后台进程想终端写数据时
23SIGURGI/O有紧急数据到达当前进程默认忽略
24SIGXCPU进程的CPU时间片到期
25SIGXFSZ文件大小的超出上限
26SIGVTALRM虚拟时钟超时
27SIGPROFprofile时钟超时
28SIGWINCH窗口大小改变默认忽略
29SIGIOI/O相关
30SIGPWR关机默认忽略
31SIGSYS系统调用异常

服务开发需要屏蔽的信号

#define SIGHUP 1 /* hangup */

SIGHUP是Unix系统管理员很常用的一个信号。许多后台服务进程在接受到该信号后将会重新读取它们的配置文件。然而，该信号的实际功能是通知进程它的控制终端被断开。缺省行为是终止进程。

#define SIGPIPE 13 /* write on a pipe with no one to read it */

SIGPIPE: 管道的作用就像电话一样，允许进程之间的通信。如果进程尝试对管道执行写操作，然而管道的另一边却没有回应者时，操作系统会将SIGPIPE信号交付给这个讨厌的进程（这里就是那个打算写入的进程）。缺省行为是终止进程。

#define SIGSYS 12 /* non-existent system call invoked */

SIGSYS信号会在进程执行一个不存在的系统调用时被交付。操作系统会交付该信号，并且进程会被终止。缺省行为是终止进程，并且创建一个核心转储。

Nginx中信号处理

/* 数组signals用来定义进程将会处理的所有信号 */
ngx_signal_t  signals[] = {
    /* SIGHUP */
    { ngx_signal_value(NGX_RECONFIGURE_SIGNAL),
      "SIG" ngx_value(NGX_RECONFIGURE_SIGNAL),
      "reload",
      ngx_signal_handler },
    
    /* SIGUSR1 */
    { ngx_signal_value(NGX_REOPEN_SIGNAL),
      "SIG" ngx_value(NGX_REOPEN_SIGNAL),
      "reopen",
      ngx_signal_handler },
    
    /* SIGWINCH */
    { ngx_signal_value(NGX_NOACCEPT_SIGNAL),
      "SIG" ngx_value(NGX_NOACCEPT_SIGNAL),
      "",
      ngx_signal_handler },
 
    /* SIGTERM */
    { ngx_signal_value(NGX_TERMINATE_SIGNAL),
      "SIG" ngx_value(NGX_TERMINATE_SIGNAL),
      "stop",
      ngx_signal_handler },
 
    /* SIGQUIT */
    { ngx_signal_value(NGX_SHUTDOWN_SIGNAL),
      "SIG" ngx_value(NGX_SHUTDOWN_SIGNAL),
      "quit",
      ngx_signal_handler },
 
    /* SIGUSR2 */
    { ngx_signal_value(NGX_CHANGEBIN_SIGNAL),
      "SIG" ngx_value(NGX_CHANGEBIN_SIGNAL),
      "",
      ngx_signal_handler },
 
    { SIGALRM, "SIGALRM", "", ngx_signal_handler },
 
    { SIGINT, "SIGINT", "", ngx_signal_handler },
 
    { SIGIO, "SIGIO", "", ngx_signal_handler },
 
    /*
    #define SIGCHLD 20 /* to parent on child stop or exit 
    SIGCHLD是由Berkeley Unix引入的，并且比SRV 4 Unix上的实现有更好的接口。（如果信号是一个没有追溯能力的过程(not a retroactive process)，那么BSD的SIGCHID信号实现会比较好。在system V Unix的实现中，如果进程要求捕获该信号，操作系统会检查是否存在有任何未完成的子进程（这些子进程是已经退出exit)的子进程，并且在等待调用wait的父进程收集它们的状态）。如果子进程退出的时候附带有一些终止信息(terminating information），那么信号处理句柄就会被调用。所以，仅仅要求捕获这个信号会导致信号处理句柄被调用(译注：即是上面说的“信号的追溯能力”)，而这是却一种相当混乱的状况。）一旦一个进程的子进程状态发生改变，SIGCHLD信号就会被发送给该进程。就像我在前面章节提到的，父进程虽然可以fork出子进程，但没有必要等待子进程退出。一般来说这是不太好的，因为这样的话，一旦进程退出就可能会变成一个僵尸进程。可是如果父进程捕获SIGCHLD信号的话，它就可以使用wait系列调用中的某一个去收集子进程状态，或者判断发生了什么事情。当发送SIGSTOP,SIGSTP或SIGCONF信号给子进程时，SIGCHLD信号也会被发送给父进程。缺省行为是丢弃该信号。
    */
    { SIGCHLD, "SIGCHLD", "", ngx_signal_handler },
 
    /*
     #define SIGSYS 12 /* non-existent system call invoked 
     SIGSYS信号会在进程执行一个不存在的系统调用时被交付。操作系统会交付该信号，
     并且进程会被终止。缺省行为是终止进程，并且创建一个核心转储。
    */
    { SIGSYS, "SIGSYS, SIG_IGN", "", NULL },
 
    /*  
     * 当服务器close一个连接时，若client端接着发数据。根据TCP协议的规定，会收到一个RST响应，client再往这个服务器发送数据时，
       系统会发出一个SIGPIPE信号给进程，告诉进程这个连接已经断开了，不要再写了。
 
    *  又或者当一个进程向某个已经收到RST的socket执行写操作是，内核向该进程发送一个SIGPIPE信号。该信号的缺省学位是终止进程，因此进程必须捕获它以免不情愿的被终止。
 
    *  根据信号的默认处理规则SIGPIPE信号的默认执行动作是terminate(终止、退出),
       所以client会退出。若不想客户端退出可以把 SIGPIPE设为SIG_IGN
    */
    { SIGPIPE, "SIGPIPE, SIG_IGN", "", NULL },
 
    { 0, NULL, "", NULL }
};

Redis信号处理

/* 分配操作所需的数据结构，设置侦听套接字等 */
/* 初始化服务器--主要工作是createSharedObjects();及aeCreateEventLoop创建事件Loop */
void initServer(void) {
    int j;
 
    signal(SIGHUP, SIG_IGN); //忽略SIGHUP信号
    signal(SIGPIPE, SIG_IGN); //忽略SIGPIPE信号

Reference

  1. https://gityuan.com/2015/12/20/signal/
  2. https://hv1oua0ifoy.feishu.cn/docx/I1UUdDxGxoS50sxsyG5cdSIonRp

Graph View