Questions tagged «signals»

这是该问题的后续措施。 我还要进行一些测试；看起来这是在物理控制台还是通过SSH进行都没关系，仅SCP也不发生这种情况。我也用进行了测试cat /dev/zero > /dev/null。行为是完全相同的： 使用在后台启动进程&（或在开始使用后将其置于后台CTRL-Z和bg）；这无需使用即可nohup完成。 注销。 重新登录。 该过程仍然存在，愉快地运行，现在是 init。 我可以确认SCP和CAT在发送了 SIGHUP；我使用进行了测试kill -HUP。 所以，看起来SIGHUP确实是 不会在注销时发送，至少不会发送到后台进程（出于显而易见的原因，不能使用前台进程进行测试）。 最初，这是通过VMware ESX 3.5（基于RedHat）的服务控制台发生的，但是我能够在CentOS 5.4上完全复制它。 问题又是：注销时是否不将SIGHUP发送到进程，即使它们在后台运行？为什么这没有发生？ 编辑 strace根据Kyle的回答，我检查了。 正如我所期望的，从启动它的外壳注销时，该过程没有任何信号。在使用服务器控制台和通过SSH时都会发生这种情况。

21 linux  bash  process  signals 

背景 我被要求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_daemonvia SIGKILL（这样我们就不会有PID被回收的风险，也不会出现针对错误PID的systemd问题SIGKILL）。我们正在测试的设备迅速产生/分叉了许多过程，因此，对于PID回收引起问题的问题很少，但确实存在。 如果实际上，我只是对PID回收抱有偏执，那么我可以接受脚本，只是SIGKILL针对进程的PID 发出脚本，而不必担心杀死回收的PID。

20 linux  service  systemd  signals 

我正在使用svn + ssh，并且看到许多： Killed by signal 15. 在期间svn up。 有什么想法吗？

17 ssh  svn  signals 

我最近与我的一个客户签约，以促进他的“家庭”办公室和辅助站点的无线通信。 主要站点是5层办公楼（大约15m高或更低）的顶层两层，辅助站点是两个开放“地块”之一（根据管理，该区域为TBD）。离第二个站点较近的站点的地面距离略大于2km，而距离最远的站点的地面距离约为2.9km。 该链接将用于传输1个（或什至两个）IP摄像机和某种支持以太网的环境或天气传感器的视频馈送。我已经检查了摄像机的必要黑白，并且900Mhz和5.8Ghz甚至足以满足其中4个摄像机的要求，而对于2个摄像机来说则绰绰有余。并且菲涅耳区60％的间隙超出了覆盖范围。请记住，这是我的第一个长距离链接（带有引号或不带引号的长距离链接），我不愿承认无线物理远非我的强项。 我的问题的最终要点是，尽管最近几天我已经阅读了很多有关频率选择的信息，但我仍然发现有一些歧义（我知道只有我才发现模棱两可）。像这样的大多数消息来源都同意，尽管较低的频率在给定的距离上损耗较小（我知道这是所谓的自由空间损耗），但对于相同的传输“强度”，它们需要较大的触角（实际上是“增益”与“强度”相同？）。 那么，对于给定的2-3km距离以及所有典型的要求都得到满足，频率是更好的（或者我敢说“更好”）？我是否应该基于3km并不是真正的“长距离”而选择具有相对“小”天线的900Mhz，并且它会为链路提供更少的衰减，更少的重传和更高的总体速度？还是我应该为上级黑白选择5.8Ghz选项（我仍然不太确定，如果有错，请更正我），因为在这个距离上没有真正的区别，所以为什么不采取“更好”的选择一？ 顺便说一句，我应该走在真正的WiFi的老路还是应该考虑专有的桥接解决方案，例如Ubiquiti的解决方案？我对他们的接入点有很多经验，并且非常满意，因此我不介意在客户中集成他们的另一种产品。无论如何，我都在寻找最佳解决方案，此时，选择供应商几乎是无关紧要的。 原谅我的无知和可能错误使用语言。 更新：我安排租借频谱分析仪几天。我将确保900Mhz频段相当清晰，然后按照这种方式进行下去。 更新2：我可以使用上述设备玩一天半。最终结论是，如此处建议的那样，该区域的9Mhz频段几乎是“空”的，因此可以解决频率选择问题。 关于设备，我将使用Ubiquiti AirMax Yagi天线和配套的RM900 2x2无线电。我本人以及客户员工的初步测试表明，性能超出了预期。 顺便说一句，选择的“地段”是3公里以外的地方。

13 wifi  wireless-bridge  signals 

有没有办法找出在Red Hat Enterprise Linux 5（SIGTERM等）中发送的信号的来源？我经常将TERM困在应用程序中，但我不知道它来自何处。

13 linux  signals 

为了建立可靠的连接，是否需要有多强的Wifi信号行业标准？例如，也许Wifi端点设计为可以可靠地连接到-70db信号的规范。 我们正在为办公室设计Wifi网络；我们有一个以db为单位的信号强度图。我们正在尝试确定其与用户实际Wifi连接的对应方式。 另外，它是否随协议或频率而变化？

9 networking  wifi  wlan  signals