我有一个看门狗应用程序.它监视我的主应用程序，它可能会因为某种原因崩溃(我知道这很糟糕，但这不是重点).
我将此看门狗编程为接受SIGUSR1信号，以停止监视我的应用程序状态.我用信号
kill -SIGUSR1 `pidof myapp`
这真的很有效.我的问题是，当我试图向一个没有内置此功能的较旧版本的看门狗发出信号时.在这种情况下，kill信号会杀死看门狗(终止进程)，这会导致进一步的复杂性(重新启动设备).
有没有办法用SIGUSR1给我的看门狗发信号，这样如果这个特定的信号没有处理，它就不会终止？
从关于信号处理的GNU docs篇文章中:
SIGUSR1和SIGUSR2信号被预留给您，供您以任何方式使用.如果在接收信号的程序中为它们编写信号处理程序，它们对于简单的进程间通信非常有用.
SIGINFO的默认操作是什么都不做，因此它可能更适合:
SIGINFO:信息请求.在4.4 BSD和GNU系统中，当用户以规范模式键入状态字符时，该信号被发送到控制终端的前台进程组中的所有进程；请参阅导致信号的字符部分.
SIGHUP在控制终端关闭时发出，但由于大多数守护进程未连接到终端，因此将其用作"重新加载"并不罕见:
守护程序有时使用SIGHUP作为重启自身的信号，最常见的原因是重新读取已更改的配置文件.
顺便说一句，你的看门狗可以不时地读取一个配置文件，以便知道它是否应该重新启动这个过程.
我个人最喜欢的看门狗是supervisor.
$ supervisorctl start someapp
someapp: started
$ supervisorctl status someapp
someapp RUNNING pid 16583, uptime 19:16:26
$ supervisorctl stop someapp
someapp: stopped
看看kill -l是否返回平台上的信号列表，并try 其中一些，但SIGUSR1似乎是一个糟糕的 Select .
$ 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
[更新]
关于Linux和BSD之间行为差异的 comments :
SIGINFO在GNU libc&；上的工作方式似乎有所不同；BSD；在BSD上，它的工作原理与您描述的一样，但在Linux上，它要么不存在，要么与SIGPWR相同...GNU libc手册在这方面似乎不正确(kill-l输出也不显示SIGINFO)...我不知道GNU为什么不支持它，因为我发现它非常有用吸烟者