Perché il mio processo è ancora in esecuzione dopo la disconnessione?

Dopo aver effettuato l'accesso ssh, digito questo comando in bash:

sleep 50000000000000 &

Quindi ho kill -9il sleepprocesso genitore del processo (cioè, bash). Quindi la finestra del terminale si disconnette contemporaneamente.

Quando eseguo nuovamente l'accesso, trovo che il sleepprocesso sia ancora attivo.

Domanda : Perché il sleepprocesso può sopravvivere quando esco e il terminale è chiuso? Nella mia mente, tutto tranne i demoni e i nohupprogrammi verranno uccisi durante il logout. Se sleepriesco a sopravvivere in questo modo, significa che posso usare questo metodo invece del nohupcomando?

Tl; dr:

Perché il sleepprocesso può sopravvivere quando esco e il terminale è chiuso? Nella mia mente, tutto tranne i demoni e i nohupprogrammi verranno uccisi durante il logout. Se sleepriesco a sopravvivere in questo modo, significa che posso usare questo metodo invece del nohupcomando?

A meno che l' bashistanza generata da non sshabbia l' huponexitopzione impostata, nessun processo verrà terminato in alcun modo all'uscita / disconnessione e quando l' huponexitopzione è impostata, l'uso kill -9sulla shell non è una buona alternativa all'utilizzo nohupsui processi figlio della shell; nohupsui processi figlio della shell li proteggerà comunque dai SIGHUP che non provengono dalla shell e anche quando ciò non nohupè importante è ancora preferibile perché consente alla shell di essere terminata con grazia.

In bashc'è un'opzione chiamata huponexit, che se impostata renderà bashSIGHUP i suoi figli all'uscita / logout;

Nelle istanze interattive senza accesso bash , come in bashun'istanza generata da gnome-terminal, questa opzione viene ignorata; se huponexitimpostato o non impostato, bashi bambini non saranno mai SIGHUPPassati bashall'uscita;

Nelle istanze di login interattive bash, come in bashun'istanza generata da ssh, questa opzione non viene ignorata (tuttavia non è impostata per impostazione predefinita); se huponexitimpostato, bashi bambini verranno SIGHUPpuliti bashall'uscita / logout; se huponexitnon è impostato, bashi bambini non verranno SIGHUPpuliti bashall'uscita / logout;

Quindi, in generale, uscire / disconnettersi da bashun'istanza di login interattiva , a meno che non huponexitsia impostata l' opzione, non farà della shell SIGHUP i suoi figli, e uscire / disconnettersi da bashun'istanza non di login interattiva non farà della shell SIGHUP i suoi figli indipendentemente;

Questo, tuttavia, è irrilevante in questo caso: l'utilizzo kill -9 sleepsopravviverà a prescindere, perché uccidere il suo processo genitore ( bash) non lascerà la possibilità a quest'ultimo di fare qualcosa al primo (cioè, ad esempio, se l' bashistanza corrente fosse bashun'istanza di accesso e l' huponexitopzione è stata impostata su SIGHUP it).

In aggiunta a questo, a differenza di altri segnali (come un segnale SIGHUP inviato a bash), un segnale SIGKILL non viene mai propagato ai processi figlio di un processo, quindi sleepnon viene nemmeno ucciso;

nohupavvia un processo immune ai segnali SIGHUP, che è qualcosa di diverso; eviterà che il processo si interrompa alla ricezione di un segnale SIGHUP, che in questo caso potrebbe essere ricevuto dall'istanza di accesso interattivo bashnel caso in cui l' huponexitopzione fosse impostata e la shell uscisse; quindi tecnicamente l'utilizzo nohupper avviare un processo in bashun'istanza di login interattiva con l' huponexitopzione unset impedirà al processo di riagganciare alla ricezione di un segnale SIGHUP, ma uscire / disconnettersi dalla shell non lo SIGHUP indipendentemente;

In generale, tuttavia, quando nohupè necessario per impedire che i segnali SIGHUP provengano dalla shell genitore, non c'è motivo di preferire il kill -9metodo on sul genitore al metodo nohupon sul figlio; invece, dovrebbe essere il contrario.

Uccidere il genitore usando il kill -9metodo non lascia al genitore la possibilità di uscire con garbo, mentre l'avvio del figlio usando il nohupmetodo consente al genitore di essere chiuso da altri segnali, come SIGHUP (per fare un esempio che ha senso nel contesto di un bambino ha iniziato a utilizzare nohup), che gli consente di uscire con grazia.

bashper impostazione predefinita non invia il segnale HUP ai processi figlio all'uscita . Più in dettaglio (grazie @kos), non lo fa mai per shell senza login .

Puoi configurare bash per farlo per le shell di login se imposta l'opzione huponexit. In un terminale, eseguire:

[romano:~] % bash -l

(questo avvia una nuova shell "login")

romano@pern:~$ shopt -s huponexit
romano@pern:~$ sleep 1234 &
[1] 32202
romano@pern:~$ exit
logout

Ora controlla il sleepprocesso:

[romano:~] % ps augx | grep sleep
romano   32231  0.0  0.0  16000  2408 pts/11   S+   15:23   0:00 grep sleep

... non in esecuzione: ha ricevuto il segnale HUP ed è uscito come richiesto.

Se sleepposso sopravvivere in questo modo, se ciò significa che posso usare questo metodo invece del nohupcomando?

kill -9non è davvero il modo in cui uno dovrebbe andare. È come sparare con una pistola alla TV per spegnerlo. Oltre al componente comico non c'è alcun vantaggio. I processi non possono essere catturati o ignorati SIGKILL. Se non si dà al processo la possibilità di terminare ciò che sta facendo e ripulire, potrebbe lasciare in giro file corrotti (o altro stato) e non sarà possibile riavviare. kill -9è l'ultima speranza, quando nient'altro funziona.

Perché il processo di sospensione può sopravvivere quando mi disconnetto e il terminale è chiuso. Nella mia mente, tutto tranne il demone e il programma nohup verranno uccisi al logout.

Cosa succede nel tuo caso:

Il processo padre di sleepè la bashshell attualmente in esecuzione . Quando tu kill -9bash, il processo bash non ha la possibilità di inviare SIGHUPa nessuno dei suoi processi figlio, perché SIGKILL(che viene inviato da kill -9) non è raggiungibile dal processo. Il processo di sospensione continua a essere eseguito. il sonno ora è diventato un processo orfano .

Il processo init (PID 1) esegue un meccanismo chiamato reparenting. Ciò significa che il processo init ora diventa il genitore di quel processo orfano. init è un'eccezione, i processi possono diventare figlio in quanto raccolgono processi che hanno perso il loro processo genitore originale. A proposito: un demone (come sshd) lo fa quando "passa in background".

Se ciò non dovesse accadere, il processo orfano in seguito (al termine) diventerebbe un processo zombi. Questo è ciò che accade quando waitpid()non viene chiamato (una responsabilità del processo genitore che non può essere riempito quando questo processo viene ucciso). init chiama waitpid()in un intervallo specifico per evitare bambini zombi.

Il &inizia il processo in background. Se digiti ps -ef, vedrai che l'ID processo parent (PPID) del tuo sonno è il tuo bash. Quindi disconnettersi e accedere nuovamente. Il processo rimarrà in esecuzione dopo il logout. Dopo aver effettuato l'accesso per la seconda volta, esegui di ps -efnuovo. Vedrai che ora il genitore del tuo processo di sonno verrà elaborato con ID "1". Questo è init, il genitore di tutti i processi.

L'uso &farà funzionare il programma come sfondo. Per vedere il programma in background usa il bgcomando e per farlo funzionare nuovamente in primo piano, esegui fg.

Sì, ci sono molti modi per mantenere il programma in esecuzione anche il terminale principale è uscito.