如果不是來自使用者，我可以追踪 SIGINT 的來源嗎？

我在 CentOS 7 機器上執行了一個長時間執行（3 小時）的 shell 腳本。該腳本執行一個帶有內部循環的循環，並curl在每次迭代中呼叫。

我正在使用PM2啟動腳本，因為它已經在系統上，並且對於管理程序很有用。但是，它似乎對 shell 腳本不利。今天早上我進來的時候，我看到 PM2 已經重啟了我的 shell 腳本 6 次。PM2 日誌說它收到了 SIGINT 並重新啟動。由於此腳本導致數據被推送到數據庫，這意味著我的數據已被推送 6 次。那不是bueno。

我是唯一登錄該框的人，因此它不是其他使用者。

所以，下一個問題是這是 PM2 中的錯誤還是合法的 SIGINT。這就引出了一個問題：如果它是合法的，它來自哪裡？在我將其作為 PM2 中的錯誤送出之前，我必須確定（如果可能的話）作業系統是否以某種方式殺死了這個程序（這似乎是最有可能的事情）。

sysdigevt.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 )

引用自：https://unix.stackexchange.com/questions/324055