프로세스의 잘못된 PID 추적 시작-재 스폰되지 않음

원래 StackOverflow 에서이 질문을했습니다. 그런 다음 이것이 더 좋은 곳이라는 것을 깨달았습니다.

delayed_job 프로세스를 모니터링하기 위해 블루 필 설정이 있습니다. (Ruby On Rails 애플리케이션)

우분투 사용하기 12.10.

우분투를 사용하여 블루 필 서비스 자체를 시작하고 모니터링하고 upstart있습니다. 내 시작 구성이 아래에 있습니다 ( /etc/init/bluepill.conf).

description "Start up the bluepill service"

start on runlevel [2]
stop on runlevel [016]

expect daemon
exec sudo /home/deploy/.rvm/wrappers/<app_name>/bluepill load /home/deploy/websites/<app_name>/current/config/server/staging/delayed_job.bluepill

# Restart the process if it dies with a signal
# or exit code not given by the 'normal exit' stanza.
respawn

나는 또한 expect fork대신에 시도했다 expect daemon. 또한 expect...줄을 완전히 제거하려고했습니다 .

기계가 부팅되면 블루 필이 정상적으로 시작됩니다.

$ ps aux | grep blue
root      1154  0.6  0.8 206416 17372 ?        Sl   21:19   0:00 bluepilld: <app_name>

여기서 bluepill 프로세스의 PID는 1154입니다. 그러나 upstart잘못된 PID를 추적하는 것 같습니다. 존재하지 않는 PID를 추적하고 있습니다.

$ initctl status bluepill
bluepill start/running, process 990

sudo블루 필 프로세스를 시작한 프로세스 의 PID를 추적하고 있다고 생각합니다 .

를 사용하여 bluepill을 강제 종료하면 bluepill 프로세스가 다시 생성되지 않습니다 kill -9.

또한 잘못된 PID가 추적되어 재부팅 / 종료 만 중단되고 매번 시스템을 하드 리셋해야한다고 생각합니다.

여기서 무엇이 문제가 될 수 있습니까?

업데이트 :

문제는 오늘 (2015 년 5 월 3 일) 우분투 14.04.2에서 유지됩니다.

문제는 sudo를 사용하기 때문이 아닙니다. 더 이상 sudo를 사용하지 않습니다. 업데이트 된 upstart 구성은 다음과 같습니다.

description "Start up the bluepill service"

start on runlevel [2]
stop on runlevel [016]

# Restart the process if it dies with a signal
# or exit code not given by the 'normal exit' stanza.
respawn

# Give up if restart occurs 10 times in 90 seconds.
respawn limit 10 90

expect daemon

script
    shared_path=/home/deploy/websites/some_app/shared

    bluepill load $shared_path/config/delayed_job.bluepill
end script

머신이 부팅되면 프로그램이 정상적으로로드됩니다. 그러나 upstart는 위에서 설명한 것처럼 여전히 잘못된 PID를 추적합니다.

주석에 언급 된 해결 방법으로 인해 중단 문제가 해결 될 수 있습니다. 그래도 시도하지 않았습니다.

꽤 늦었지만 다른 사용자에게 도움이 될 수 있기를 바랍니다.

forkupstart 구성에 잘못된 스탠자 를 지정하면 initctl이 잘못된 PID를 추적 할 수있는 문서화 된 버그가 있습니다 . https://bugs.launchpad.net/upstart/+bug/406397

upstart는 fork스탠자를 점검하고 제어되는 프로그램의 "참"PID를 선택하기 전에 점검해야하는 분기 프로세스 수를 결정합니다. 당신이 지정하는 경우 expect fork또는 expect daemon그러나 프로그램이 충분한 횟수 포크하지 않습니다 start중단됩니다. 반면에 프로세스가 너무 많은 포크로 처리 initctl되면 잘못된 PID를 추적합니다. 이론적으로, upstart cookbook 의이 섹션에 문서화되어야 하지만,이 상황에서 볼 수 있듯이 강제 종료 된 프로세스와 관련된 PID가 있어야합니다.

이것의 의미는 버그 추적기 주석에 설명되어 있지만 여기에 요약하겠습니다. initctl데몬 프로세스를 중지 할 수 없으며 문서화되지 않은 / 불법 상태에 머물러있는 <service> start/killed, process <pid>경우 PID에 속하는 프로세스가 중지되면 일반적으로 ) 그런 다음 시스템에서 재사용 할 수 있도록 PID가 해제됩니다.

당신이 실행하는 경우 initctl stop <service>또는 service <service> stop, initctl그 PID에게 나타나는 다음 번에 죽일 것이다. 즉, 실수를 한 후에 재부팅하지 않으면 해당 PID를 사용하는 다음 프로세스가 initctl데몬이 아니더라도 즉시 종료 됩니다. 이처럼 간단 cat하거나 복잡한 것일 수 있으며 ffmpeg일상적인 작업 중에 소프트웨어 패키지가 충돌 한 이유를 파악하기가 어려울 수 있습니다.

따라서 문제는 expect데몬 프로세스가 실제로 만드는 포크 수에 대해 잘못된 옵션을 지정했다는 것 입니다. 그들은이 문제를 해결하는 재시동 재 작성이 있다고 말하지만, 신생 1.8 (최신 Ubuntu 13.04 / 2014 년 1 월)부터는 여전히 문제가 있습니다.

expect daemon이 문제 를 사용 하고 끝내기 때문에 시도해 보는 것이 좋습니다 expect fork.

편집 : 다음 은 사용 가능한 프로세스 ID 주소 공간이 소진 될 때까지 프로세스를 생성 하는 Ubuntu BASH 호환 스크립트 ( Wade Fitzpatrick가 원본으로 수정 한 것 sleep)입니다.이 시점에서 0에서 다시 시작하여 "고정" PID. 그런 다음 PID initctl가 끊어 지면 프로세스가 생성되고 프로세스가 종료 initctl되고 재설정됩니다.

#!/bin/bash

# usage: sh /tmp/upstart_fix.sh <pid>

sleep 0.001 &
firstPID=$!
#first lets exhaust the space
while (( $! >= $firstPID ))
do
    sleep 0.001 &
done

# [ will use testPID itself, we want to use the next pid
declare -i testPID
testPID=$(($1 - 1))
while (( $! < $testPID ))
do
    sleep 0.001 &
done

# fork a background process then die so init reaps its pid
sleep 3 &
echo "Init will reap PID=$!"
kill -9 $$
# EOF

제공된 예제의 경우 :

$ initctl status bluepill
bluepill start/running, process 990

나를위한 빠른 해결책은 다음과 같습니다.

# If upstart gets stuck for some job in stop/killed state
export PID=990
cd /usr/local/bin
wget https://raw.github.com/ion1/workaround-upstart-snafu/master/workaround-upstart-snafu
chmod +x workaround-upstart-snafu
./workaround-upstart-snafu $PID

출처 : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582745#37

도움이 되길 바랍니다. 진행중인 것은 다른 답변에 설명되어 있습니다.

Upstart 사용자 레벨 작업을 실행 하거나 setuid 스탠자를 사용 하지 않는 한 작업은 루트로 실행됩니다.

Upstart가 이미 루트로 실행 중이므로 exec스탠자 에서 sudo를 전혀 사용해야하는 이유는 무엇입니까?

사용 sudo또는 su에 exec당신이 여기에서 설명하는대로 나를 위해 같은 문제를 스탠자 발생했다.

일반적으로 항목 1 또는 1과 2를 모두 경험합니다.

1. upstart는 잘못된 PID를 따릅니다.
2. 프로세스를 중지하려고하면 가동이 중단됩니다

물론, expect스탠자가 올바른 수의 포크를 반영하도록해야합니다.

YMMV, 그러나 나를 위해 :

• exec스탠자 에서 sudo 또는 su를 올바른 수의 지정된 포크로 사용하면 위의 상황 1이 발생합니다.
• 잘못된 수의 포크를 지정하면 (sudo / su가없는 exec) 위의 상황 1과 2가 발생합니다.