我想我可能已经做错了一段时间，因为我们刚刚切换到systemd，它认为我的干净杀死的进程已经结束不成功。
基本上，我监听SIGHUP，SIGINT和SIGTERM，然后（通过将信号代码传递回main）干净地例如。return 128+SIGHUP。
我希望这是用来填充$?，但现在我想我明白了，shell负责给$?这样一个值，然后 * 只有在信号未处理 *。因此，即使进程最终由于信号而退出，由于信号被处理，$?最终将成为0，并且所有信号与退出有关的证据都将丢失。是这样吗？
当处理SIGHUP并干净退出时，我是否应该从main中删除return EXIT_SUCCESS？
3条答案
按热度按时间bksxznpy1#
返回
128 + <signal number>的约定是由高级Bash脚本指南（https://stackoverflow.com/a/1535733/567292）推广的，但仅适用于程序由于接收信号而失败的情况。如果你的程序接收到信号，不处理它，并因此终止，退出状态（如提供的，例如由
wait）将是类似的，但是代替比特7设置，将具有更高的比特设置以指示WIFSIGNALED，而不是WIFEXITED。如果你在shell中运行，这会被shell翻译为128-255范围内的退出状态（$?）（即设置了第7位），所以就shell脚本而言，返回128+n的程序与由于信号未处理而终止的程序是无法区分的：[...]使用特殊参数'？“，则 shell 应报告可用的全部8位退出状态。因收到信号而终止的命令的退出状态应报告为大于128。
如果你的程序收到一个信号，然后成功退出，这被认为是一个成功的终止，所以你的程序应该返回
EXIT_SUCCESS。shyt4zoc2#
返回代码通常是您指定的代码。当你想包含退出代码的信号时，你必须确保它们仍然是唯一的。
如果你不需要退出代码中的信号，似乎没有理由包括它们。
是否返回
EXIT_SUCCESS或EXIT_FAILURE由您/您的程序决定，无论终止计算为成功还是失败。cs7cruho3#
为什么你的程序应该在信号上返回一个非零的退出代码，即使你的程序很好地清理了一切，一个原因是如果你的程序在Bash脚本中使用，比如：
用户按ctrl-c，它将终止
your_program，但next_program将继续运行，这不是用户所期望的。报告此问题的示例：https://github.com/conan-io/conan/issues/2360
我认为在守护进程中，返回0可能更合理。