web-dev-qa-db-ja.com

SIGINTがユーザーのものではない場合、どこから来たかを追跡できますか？

CentOS 7マシンで長時間（3時間）のシェルスクリプトを実行しています。スクリプトは内側のループでループを実行し、各反復でcurlを呼び出します。

スクリプトは PM2 で開始しています。スクリプトは既にシステム上にあり、プロセスの管理に適しているためです。ただし、シェルスクリプトには適さない可能性があります。今朝、PM2がシェルスクリプトを6回再起動したことを確認しました。 PM2ログは、SIGINTを受信して​​再起動されたと述べています。このスクリプトにより、データがデータベースにプッシュされるため、データが6回プッシュされました。それはブエノではありません。

ボックスにログインするのは私だけなので、別のユーザーではありません。

したがって、次の質問は、これがPM2のバグなのか、正当なSIGINTなのかです。どちらが問題を引き起こしますか？それが合法である場合、それはどこから来ますか？これをPM2のバグとして送信する前に、OSがなんらかの理由でこのプロセスを強制終了しているかどうかを（可能であれば）判断する必要があります（最も可能性が高いようです）。

linuxsignalsdebugging
7
jcollum

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 )
9
thrig