这是这个问题的后续。

我还进行了一些测试；看起来这是在物理控制台上完成还是通过 SSH 完成并不重要，这也不仅仅发生在 SCP 上；我也用cat /dev/zero > /dev/null. 行为完全相同：

• 在后台使用启动一个进程&（或者在它开始使用后把它放在后台使用CTRL-Zand bg）；这是在不使用nohup.
• 注销。
• 重新登录。
• 进程还在那里，愉快地运行着，现在是init.

如果发送，我可以确认 SCP 和 CAT 都立即退出SIGHUP；我使用kill -HUP.

因此，看起来 SIGHUP 确实不会在注销时发送，至少不会发送到后台进程（由于显而易见的原因，无法使用前台进程进行测试）。

这发生在我最初使用 VMware ESX 3.5（基于 RedHat）的服务控制台时，但我能够在 CentOS 5.4 上完全复制它。

问题再次出现：是否应该在注销时将 SIGHUP 发送到进程，即使它们在后台运行？为什么这没有发生？

编辑

strace根据凯尔的回答，我检查了。
正如我所期望的那样，从启动它的 shell 注销时，该进程没有收到任何信号。在使用服务器的控制台和通过 SSH 时都会发生这种情况。

背景

我被要求systemd为新服务创建一个脚本，该脚本foo_daemon有时会进入“不良状态”，并且不会通过SIGTERM（可能是由于自定义信号处理程序）而死亡。这对开发人员来说是有问题的，因为他们被指示通过以下方式启动/停止/重新启动服务：

• systemctl start foo_daemon.service
• systemctl stop foo_daemon.service
• systemctl restart foo_daemon.service

问题

有时，由于foo_daemon进入不良状态，我们不得不通过以下方式强行杀死它：

• systemctl kill -s KILL foo_daemon.service

题

我如何设置我的systemd脚本，foo_daemon以便每当用户尝试停止/重新启动服务时，systemd将：

• 尝试正常关闭foo_daemonvia SIGTERM。
• 最多给 2 秒的时间foo_daemon来完成关闭/终止。
• 如果进程仍然存在foo_daemon，SIGKILL则尝试强制关闭via （因此我们没有 PID 被回收的风险以及错误 PID 的systemd问题SIGKILL）。我们正在测试的设备会快速生成/分叉多个进程，因此对于 PID 回收导致问题存在罕见但非常真实的担忧。
• 如果在实践中，我只是对 PID 回收感到偏执，那么我可以接受脚本只是SIGKILL针对进程的 PID发出，而不必担心杀死回收的 PID。

我正在使用 svn+ssh，我看到了一些：

Killed by signal 15.

在svn up.

有什么想法吗？

有没有办法找出在 Red Hat Enterprise Linux 5（SIGTERM 等）中发送的信号的来源？我经常在应用程序中捕获一个 TERM，我不知道它来自哪里。

我最近与我的一个客户签订了合同，以促进他的“家庭”办公室和辅助站点的无线通信。

主要场地是一栋 5 层办公楼（或多或少 15m 高）的顶部两层，次要场地是两个开放的“地块”之一（其中一个是管理层待定）。离二级站点的地面距离，近的距离2km多一点，最远的距离2.9km左右。

该链路将用于传输 1 个（甚至可能是两个）IP 摄像机和某种支持以太网的环境或天气传感器的视频馈送。我已经检查了摄像机的必要黑白，900Mhz 和 5.8Ghz 对其中的 4 个都绰绰有余，对于 2 个更是如此。我还验证了两个可能的安装点都有清晰的视线并且超过 60% 的菲涅耳区间隙已被覆盖。请记住，这是我的第一个长距离链接（带引号或不带引号的长链接），我不愿承认无线物理远非我的强项。

我的问题的最终要点是，虽然我在过去几天阅读了很多关于频率选择的内容，但我仍然发现一些歧义（我知道只有我觉得它有歧义）。大多数消息来源，比如这个，同意尽管较低频率在给定距离内的损耗较小（我了解到它被称为自由空间损耗），但它们需要更大的天线才能获得相同的“强度”传输（实际上是“增益”）与“强度”相同？）。

那么，对于给定的 2-3 公里距离，并且还满足所有典型要求，哪个频率更可取（或者我敢说“更好”）？我是否应该选择带有相对“小”天线的 900Mhz，因为 3km 并不是真正的“长距离”，并且它会提供一个衰减更少的链路，更少的重传，更高的整体速度？或者我应该为高级黑白选择 5.8Ghz 选项（我对此仍然不是很确定，如果错误，请纠正我），因为在这个距离上没有真正的区别，所以为什么不选择“更好”一？

附带说明一下，我应该坚持使用真正的 WiFi 还是应该考虑像Ubiquiti那样的专有桥接解决方案？我对他们的接入点有很多经验，我真的很满意，所以我不介意在我的客户中再集成一种他们的产品。在任何情况下，我都在寻找最佳解决方案，此时供应商的选择并不重要。

原谅我的无知和可能的语言错误使用。

更新：我安排租用一台频谱分析仪几天。我将确保 900Mhz 频段相当清晰，然后继续往下走。

更新 2：我有上述设备可以玩一天半。结论性的发现是该地区的 9Mhz 频段几乎是“空的”，正如这里所建议的那样，因此可以解决频率选择问题。

关于现在的设备，我将使用 Ubiquiti AirMax Yagi 天线和匹配的 RM900 2x2 无线电。我和客户员工的初步测试表明，性能超出了预期。

附带说明一下，选择的“地段”是 3 公里外的地段。

是否有关于 Wifi 信号需要多强才能获得可靠连接的行业标准？例如，也许 Wifi 端点的设计规范是它们可靠地连接到 -70db 信号。

我们正在为办公室设计 Wifi 网络；我们在db中有一个信号强度图。我们正在尝试确定这将如何与用户的实际 Wifi 连接相对应。

此外，它是否因协议或频率而异？

TILdocker kill意思是“杀死”，意思是“让它死”，而不是 POSIX 意义上的“发送信号”。

我们有几个集装箱需要发送SIGHUP以重新加载配置，但这会导致它们忽略“始终”的重新启动策略，这不是我们想要的。

在不影响这些容器自动重启能力的情况下向这些容器发送信号的最佳方式是什么？

为了更清楚地展示我们所看到的问题，请看以下示例。

我们有一些容器的重启策略设置为始终

$ docker inspect cloudwatch-exporter | jq .[].HostConfig.RestartPolicy\n{\n  "Name": "always",\n  "MaximumRetryCount": 0\n}\n

我们在某个时候重新加载配置docker kill：

$ docker kill --signal=SIGHUP cloudwatch-exporter\ncloudwatch-exporter\n

一段时间后，发生了一些事情终止了该进程。为了模拟这一点，我将在容器内发送一个信号：

$ docker exec cloudwatch-exporter bash -c "kill 1"\n

此时，容器已死亡并且不会重新启动：

$ docker ps -a | grep cloudwatch-exporter\nc7827204bba5        prom/cloudwatch-exporter:cloudwatch_exporter-0.8.0                                "java -jar /cloudwat\xe2\x80\xa6"   20 hours ago        Exited (143) 3 minutes ago                            cloudwatch-exporter\n

我们有哪些替代方案可以使用docker kill …

我有很多守护进程有时会在数据库事务期间挂起，从而阻止其他查询（并造成普遍的破坏）

为了调试，我在守护进程中添加了一些代码，以便在向其发送 SIGCONT 信号时转储堆栈跟踪。

在未停止的进程上捕获 SIGCONT 通常是否安全？

如果没有设置捕获它，我想使用一个不会终止进程的信号

我有一堆服务负责运行从队列中消耗的操作。

我希望能够轻轻地重新启动服务（不中断已经在运行的操作）

可以通过处理 systemd 发送的 SIGTERM 并保存程序在处理当前操作后应退出的信息来解决。
还有一个小问题是，TimeoutStopSec在服务配置文件中定义的一段时间后，systemd 将发送额外的 SIGKILL 来残酷地终止我的进程。
我可以通过设置轻松避免它TimeoutStopSec=infinity。然后systemctl stop等到脚本自行终止，这可能会持续一个多小时，并导致我遇到主要问题。

我不希望systemctl命令等到脚本结束

看起来SendSIGKILL=no配置可以完成这项工作。这会导致SIGTERM在之后重试TimeoutStopSec，然后创建新的工作线程，并让旧的工作线程继续运行。

日志控制日志

May 06 14:14:43 jaku systemd[1]: Stopping Jaku test worker...
May 06 14:14:43 jaku python3[31597]: * 15 <frame object at 0x14d8108>
May 06 14:14:53 jaku systemd[1]: jaku-test-worker.service: State 'stop-sigterm' timed out. Skipping SIGKILL.
May 06 14:14:53 jaku python3[31597]: * 15 <frame object at 0x14d8108>
May 06 14:15:03 jaku systemd[1]: jaku-test-worker.service: State …

在这个关于 SO 的答案中，我举了一个例子，它应该在提交给at的作业中使用 -SIGCONT 信号。但是，我发现我用 -SIGSTOP 停止的进程并没有继续。当我将信号更改为数值时，它起作用了。

echo "kill -18 $rspid"|at now + 2 minutes

使用数值是一个坏主意，因为它在不同的系统上可能不同。

如何使用符号信号 (-SIGCONT) 而不是数字信号 (-18) 提交此作业？