☰

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 )

관련 정보