avvia il demone sul server remoto tramite lo script di shell SSH di Jenkins esce misteriosamente

Ho un lavoro di compilazione su jenkins che sta costruendo il mio progetto e dopo averlo fatto apre uno script di shell ssh su un server remoto e trasferisce i file e poi si ferma avvia un daemon.avvia il demone sul server remoto tramite lo script di shell SSH di Jenkins esce misteriosamente

Quando si arresta e si avvia il daemon dalla riga di comando su un server RHEL, viene eseguito correttamente. Quando il lavoro viene eseguito in jenkins, non ci sono errori.

Il demone si ferma e si avvia correttamente. Ma poco dopo l'inizio, il demone muore improvvisamente.

sudo service daemonName stop 
# transfer files. 
sudo service daemonName start

Sono sicuro che il problema non è Pathing

Qualcuno sa quello che potrebbe essere speciale per il modo in cui Jenkins sta eseguendo lo script di shell ssh che causerebbe il demone inizia a non pienamente completa?

fonte

2013-05-21 Eric

Avete controllato i registri? Quali errori leggi lì? – fedorqui

i log del jenkins? o i registri della console? o i log del demone? i registri della console mostrano che tutto è andato a buon fine. I log del demone non mostrano alcun problema Il log di jenkins dubito sarà utile. – Eric

Forse il daemon non è demonizzato correttamente, hai provato ad aggiungere un 'sleep 10000' allo script della shell in Jenkins per vedere se è più lungo quando la shell invocante non è chiusa? Hai provato a confrontare l'output di 'env' in Jenkins e la shell? Se è un demone homegrown, potrebbe essere influenzato da cose come le impostazioni locali. –

Il problema: Quando si esegue una build attraverso Jenkins, il comando per avviare il processo demone era chiaramente in esecuzione con successo, ma dopo la il lavoro di compilazione è stato fatto, il demone si sarebbe improvvisamente chiuso.

La soluzione: Ho pensato per tutto questo tempo che era jenkins a uccidere il demone. Così ho provato molte diverse incarnazioni e permutazioni di disabilitare il modulo ProcessTree che passa attraverso e pulisce i processi figlio di zombie. Ho provato a ingannarlo ripristinando la variabile di ambiente BUILD_ID. Niente ha funzionato

Grazie a questo thread ho scoperto che questa soluzione funziona solo per i processi figlio eseguiti sulla macchina BUILD. OSSIA non applicabile al mio problema.

più alla ricerca mi ha portato qui: Run a persistent process via ssh

La soluzione? Nohup.

Così ora l'accumulo riavvia correttamente il demone eseguendo il seguente: il servizio nohup sudo daemonname Iniziamo

fonte

2013-06-07 21:51:09 Eric

nohup salvato anche me ... ma stranamente non ha funzionato quando ho aggiunto '&' alla fine della riga. Ho dovuto omettere '&' perché l'invocazione dello script remoto funzioni. – noumenon

Jenkins osserva i processi generati dal lavoro e li uccide per evitare i processi di zombi. Vedere https://wiki.jenkins-ci.org/display/JENKINS/ProcessTreeKiller

La soluzione è di ignorare la variabile BUILD_ID ambiente:

BUILD_ID=dontKillMe

fonte

2013-05-21 19:05:54 rcomblen

Ok, ho provato questo in molte incarnazioni diverse ma non sembra funzionare.Ho provato ad aggiungere il flag di spegnere il killer albero processo, ho provato a cambiare la build id nello script SSH sto eseguendo ID build = dontKillMe servizio sudo start servicename si trova in una "esecuzione di shell script su host remoto su ssh " Sto facendo qualcosa di sbagliato? – Eric

ok, sembra che io abbia letto male la tua domanda. Il processo tre killer funziona solo sul nodo jenkins (o sugli slave collegati) ma non sulla macchina remota, quindi la fonte del problema deve essere altrove. – rcomblen

Sono contento che tu l'abbia fatto, la tua risposta ha appena risolto un mio mal di testa lungo giorno. Grazie =) –

avvia il demone sul server remoto tramite lo script di shell SSH di Jenkins esce misteriosamente

risposta

Problemi correlati