Question

我有一个看门狗应用程序。它看着我的主要应用程序，可能因为某种原因而崩溃（我知道这很糟糕，但这不是重点）。

我将这个看门狗编程为接受SIGUSR1信号，以停止监控我的应用程序存在。我用

发出信号

kill -SIGUSR1 `pidof myapp`

这非常有效。当我尝试发出没有内置此功能的旧版看门狗时，我的问题出现了。在这种情况下，kill信号会杀死看门狗（终止进程），这会导致进一步的复杂化（重启设备）

有没有办法用SIGUSR1向看门狗发出信号，以便在未处理此特定信号时它不会终止？

Answer 1

关于信号处理的GNU docs：

SIGUSR1和SIGUSR2信号可供您随意使用。如果在接收信号的程序中为它们编写信号处理程序，它们对于简单的进程间通信很有用。有一个示例显示SIGUSR1和SIGUSR2在Signaling Another Process部分中的使用。 默认操作是终止流程。

SIGINFO的默认操作是什么都不做，所以它可能更合适：

SIGINFO：信息请求。在4.4 BSD和GNU系统中，当用户在规范模式下键入STATUS字符时，该信号被发送到控制终端的前台进程组中的所有进程;请参阅导致信号的字符部分。如果进程是进程组的领导者，则默认操作是打印有关系统的一些状态信息以及进程正在执行的操作。 否则默认为什么都不做。

当控制终端关闭时会发出

SIGHUP，但由于大多数守护程序没有连接到终端，因此将其用作“重新加载”并不罕见：

守护程序程序有时会使用SIGHUP作为重新启动的信号，这是重新读取已更改的配置文件的最常见原因。

BTW，您的看门狗可以不时读取配置文件，以了解它是否应该重新启动该过程。

我个人最喜欢的看门狗是supervisor。

$ supervisorctl start someapp
someapp: started

$ supervisorctl status someapp
someapp                RUNNING    pid 16583, uptime 19:16:26

$ supervisorctl stop someapp
someapp: stopped

看看kill -l是否返回平台上的信号列表并尝试其中一些，但SIGUSR1似乎是一个糟糕的选择。

$ kill -l
 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR
31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7
58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
63) SIGRTMAX-1  64) SIGRTMAX

[UPDATE]

Carpetsmoker评论Linux和BSD之间的行为差异：

SIGINFO似乎在GNU libc＆amp; BSD;在BSD上，它可以像你描述的那样工作，但在Linux上，它要么不存在，要么与SIGPWR相同...... GNU libc手册在这方面似乎不正确（你的kill -l输出也没有显示SIGINFO））... ...我不知道为什么GNU不支持它，因为我发现它非常有用...... - Carpetsmoker

Answer 2

接收SIGUSR1时的默认操作是在处理程序不存在时终止。这意味着你不能再用那个信号做你想做的事了。

没有更新看门狗，你无能为力（我假设在发送信号之前你无法区分程序内的看门狗版本）。

如何在不杀死Linux的情况下发出应用程序信号？

2 个答案: