İşlemin yanlış PID'sini izlemeye başlama - yeniden doğma yok

Aslında bu soruyu StackOverflow üzerinde sordum. Sonra bu muhtemelen daha iyi bir yer olduğunu fark etti.

Benim delayed_job süreçlerimi izlemek için bluepill kurulum var. (Ruby On Rails uygulaması)

Ubuntu Kullanımı 12.10.

Ubuntu'yu kullanarak bluepill servisinin kendisini başlatıp izliyorum upstart. Benim start-up yapılandırmam aşağıda ( /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

Ben de expect forkyerine denedim expect daemon. Ayrıca expect...hattı tamamen kaldırmayı denedim .

Makine önyüklendiğinde, bluepill iyi çalışmaya başlar.

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

Bluepill işleminin PID'si burada 1154'tür. Ancak upstartyanlış PID'yi izliyor gibi görünüyor. Var olmayan bir PID'yi izliyor.

$ initctl status bluepill
bluepill start/running, process 990

sudoBluepill sürecini başlatan sürecin PID'sini takip ettiğini düşünüyorum .

Bu, bluepill'i zorla öldürürsem bluepill sürecinin yeniden doğmasını önler kill -9.

Dahası, yanlış PID'nin izlenmesinden dolayı, yeniden başlatma / kapatma sadece askıda kalıyor ve her seferinde makineyi sıfırlamak zorundayım.

Burada sorun ne olabilir?

GÜNCELLEME :

Sorun bugün (3 Mayıs 2015) Ubuntu 14.04.2'de devam ediyor.

Sorun sudo kullanmaktan kaynaklanmıyor. Artık sudo kullanmıyorum. Güncellenmiş uptart yapılandırmam şudur:

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

Makine önyükleme yaptığında, program iyi yüklenir. Ancak uptart, yukarıda açıklandığı gibi hala yanlış PID'yi izler.

Yorumlarda belirtilen geçici çözüm, askıya alma sorununu çözebilir. Yine de denemedim.

Oldukça geç, ama umarım bu diğer kullanıcılara yardımcı olabilir.

Uptart forkyapılandırmasında yanlış stanza belirtirseniz, uptart'da initctl'in yanlış PID'yi izlemesine neden olabilecek belgelenmiş bir hata vardır : https://bugs.launchpad.net/upstart/+bug/406397

Ne olur? Uptart, stanzayı kontrol eder forkve kontrol edilen programın "gerçek" PID'sini seçmeden önce kaç çatallı sürecin kontrol etmesi gerektiğini belirler. Belirtirseniz expect forkveya expect daemonprogramınız yeterli sayıda çatal atmazsa start, askıda kalacaktır. Öte yandan, işleminiz çok kez çatallanırsa initctl, yanlış PID'yi izler. Teorik olarak, uptart yemek kitabının bu bölümünde belgelenmelidir , ancak bu durumda görebileceğiniz gibi, olmaması gereken durumlarda öldürülen süreçle ilişkili bir PID vardır.

Bunun etkilerini bugtracker yorumlarla açıklanmıştır, ama burada özetlemek gerekir: yanında initctlservis sürecini durdurmak mümkün ve belgesiz / kaçak durumda sıkışmış olmama <service> start/killed, process <pid>proses PID durdurur ait ise, (ve genellikle olacak ) daha sonra PID, sistem tarafından yeniden kullanılmak üzere serbest bırakılır.

Eğer sorunu varsa initctl stop <service>ya service <service> stop, initctlo PID göründüğü sefere öldürecektir. Bu, bu hatayı yaptıktan sonra yeniden başlatmazsanız, yolun bir yerinde, bu PID'yi kullanmanın bir sonraki işleminin initctl, arka plan programı olmasa bile hemen öldürüleceği anlamına gelir. Bu kadar basit catveya karmaşık bir şey olabilir ffmpegve yazılım paketinizin neden bazı rutin işlemlerin ortasında çöktüğünü anlamakta zorlanırsınız.

Yani, sorun, expectdaemon işleminizin gerçekten yaptığı çatal sayısı için yanlış bir seçenek belirtmenizdir . Bu konuyu ele alan bir yeniden başlatma yeniden yazımı olduğunu söylüyorlar, ancak upstart 1.8'den (en son Ubuntu 13.04 / Ocak 2014) sorun hala devam ediyor.

expect daemonBu sorunu kullandığınız ve sona erdirdiğiniz için denemenizi öneririz expect fork.

Düzenleme: İşte , mevcut işlem kimliği adres alanı tükenene kadar süreçleri doğuran, o noktada 0'dan başlar ve "sıkışmış" yolunda çalışan bir Ubuntu BASH uyumlu komut dosyası ( Ubuntu kullanmak için değiştirilmiş Wade Fitzpatrick tarafından orijinalsleep ) PID. Daha sonra PID kapatıldığında bir süreç ortaya çıkar initctlve initctlöldürür ve sıfırlanır.

#!/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

Verilen örnek için:

$ initctl status bluepill
bluepill start/running, process 990

benim için hızlı bir çözüm:

# 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

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

Umuyorum ki faydalı olacaktır. Olanlar diğer cevaplarda açıklanıyor.

Upstart kullanıcı düzeyinde bir iş çalıştırmadığınız veya setuid stanza'yı kullanmadığınız sürece , işiniz kök olarak çalışır.

Upstart zaten kök olarak çalıştığından, neden sudo'yu stanzada kullanmanız gerekiyor exec?

Kullanılması sudoveya suiçinde execburada tarif benim için aynı sorunları dörtlük neden olmuştur.

Genellikle madde 1 VEYA hem 1 VE 2 yaşayacak:

1. upstart yanlış PID'yi izliyor
2. İşlemi durdurmaya çalıştığımda uptart kilitleniyor

Tabii ki, ek olarak expectstanzaların doğru çatal sayısını yansıtması gerekir .

YMMV, ama benim için:

• execstanzada, belirtilen sayıda çatal ile sudo veya su kullanılması genellikle yukarıdaki 1. durumla sonuçlanır.
• Yanlış çatal (belirtilen sudo / su olmadan exec) yukarıdaki 1 ve 2 durumlarına neden olur.