☰

SIGINTがユーザーから来ていない場合は、そのソースを追跡できますか？

tag-icon • tag-icon linux signals debugging
SIGINTがユーザーから来ていない場合は、そのソースを追跡できますか？

CentOS 7システムで長時間（3時間）実行されるシェルスクリプトがあります。スクリプトは内部ループを使用してループを実行し、curl繰り返しごとに呼び出されます。

スクリプトを起動します微粒子すでにシステムにあり、管理プロセスを容易にするためです。ただし、シェルスクリプトでは正しく機能しない可能性があります。今朝来たとき、PM2が私のシェルスクリプトを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 )

関連情報