☰

如果 SIGINT 不是来自用户，我可以追踪它的来源吗？

tag-icon • tag-icon linux signals debugging
如果 SIGINT 不是来自用户，我可以追踪它的来源吗？

我有一个在 CentOS 7 机器上运行很长时间（3 小时）的 shell 脚本。该脚本运行一个带有内部循环的循环，并curl在每次迭代中调用。

我开始脚本颗粒物因为它已经在系统上并且有利于管理流程。然而，它似乎对于 shell 脚本来说可能不太好。当我今天早上进来时，我看到 PM2 重新启动了我的 shell 脚本 6 次。 PM2 日志显示它收到了 SIGINT 并已重新启动。由于此脚本导致数据被推送到数据库，这意味着我的数据已被推送 6 次。那不是布埃诺。

我是唯一登录该框的人，因此不是其他用户。

因此，下一个问题是这是 PM2 中的错误还是合法的 SIGINT。这就引出了一个问题：如果它是合法的，它来自哪里？在我将其作为 PM2 中的错误提交之前（这似乎是最有可能的事情），我必须确定（如果可能的话）操作系统是否以某种方式终止了该进程。

答案1

sysdig可以使用过滤器监视这些evt.type=kill：

# terminal uno
perl -E 'warn "$$\n"; $SIG{INT}= sub { die "aaaaargh" }; sleep 999'

# terminal dos
sysdig -p '%proc.pname[%proc.ppid]: %proc.name -> %evt.type(%evt.args)' evt.type=kill

# terminal tres
kill -INT 11943  # or whatever

可能需要更具体的过滤器，以避免systemd垃圾邮件等使输出混乱sysdig，或者grep针对您的进程名称或 pid：

# sysdig -p '%proc.pname[%proc.ppid]: %proc.name -> %evt.type(%evt.args)' evt.type=kill
systemd[1]: systemd-udevd -> kill(pid=11969(systemd-udevd) sig=15(SIGTERM) )
systemd[1]: systemd-udevd -> kill(res=0 )
systemd[1]: systemd-udevd -> kill(pid=11970(systemd-udevd) sig=15(SIGTERM) )
systemd[1]: systemd-udevd -> kill(res=0 )
systemd[1]: systemd-udevd -> kill(pid=11971(systemd-udevd) sig=15(SIGTERM) )
systemd[1]: systemd-udevd -> kill(res=0 )
sshd[11945]: bash -> kill(pid=11943(perl) sig=2(SIGINT) )
sshd[11945]: bash -> kill(res=0 )

相关内容