☰

"그런 프로세스 없음"을 유발하기 위해 pidof와 kill 사이에 무슨 일이 일어날 수 있습니까?

tag-icon • tag-icon process cron kill pidof
"그런 프로세스 없음"을 유발하기 위해 pidof와 kill 사이에 무슨 일이 일어날 수 있습니까?

나는 꽤 많은 코드를 상속받았고 매 시간마다 서비스를 다시 시작하는 크론 작업을 보고 있습니다. 다른 스크립트는 이 프로세스를 건드리고 이 코드를 실행하지 않습니다.

#The name of the process has been scrubbed to protect the guilty

procpid=$( pidof proc )
if [ -n "$procpid" ]; then
  kill -HUP $procpid
  procpid=$( pidof proc )
  if [ -z "$procpid" ]; then
    error "PROC ain't running, go figure out why"
  fi
fi

이것은 99.9999%의 시간 동안 작동합니다. 문제는 저는 설명할 수 없는 syslog 메시지가 이메일로 전송되는 것을 싫어하는 5-9 사람이라는 것입니다. 그 이유는 다음과 같습니다.

Kill: (1076) - 해당 프로세스가 없습니다.

거기 계속 나타나세요. 이는 "if"와 "kill" 사이에 내 프로세스를 죽이는 다른 무언가가 있다는 것을 반드시 의미합니까, 아니면 더 교활한 일이 진행되고 있습니까?

이 코드는 문제가 없고 다른 코드가 실제로 두 줄 사이의 프로세스를 종료할 가능성이 매우 높으므로 최소한 이러한 경고가 표시되는 이유를 디버그하는 데 사용할 수 있는 "무엇이 나를 죽였는가" 진단 클래스 검사기가 있습니까?

답변1

pidof더 이상, 특히 관련된 프로세스의 성격을 알지 못한 채, 나는 그것이 와 사이에서 사라지고 있는 것 같다고 말해야 할 것입니다 kill. killall기본적으로 전체 코드 블록 대신 . 경쟁 조건은 여전히 ​​존재하지만 기간은 더 짧아집니다.

이 코드는 문제가 없고 다른 코드가 실제로 두 줄 사이의 프로세스를 종료할 가능성이 매우 높으므로 최소한 이러한 경고가 표시되는 이유를 디버그하는 데 사용할 수 있는 "무엇이 나를 죽였는가" 진단 클래스 검사기가 있습니까?

UNIX에는 신호가 기록되지 않으므로 일반적으로 "무엇이 나를 죽였는가"를 알 수 있는 방법이 없습니다. 최소한 쉽게 할 수 있는 일은 래퍼 쉘 스크립트에서 관련 프로세스를 실행하는 것입니다. 최소한 프로세스가 종료된 이유를 기록합니다.

#!/bin/sh

proc
logger "proc died with status $?"

$?프로세스가 정상적으로 종료되면 0에서 127 사이이고, 신호 수신으로 인해 프로세스가 종료되면 128보다 크고 신호 번호는 $?-128입니다.

관련 정보