Qual è la differenza tra nohup e e commerciale

Entrambi nohup myprocess.out &o myprocess.out &impostare myprocess.out per l'esecuzione in background. Dopo aver spento il terminale, il processo è ancora in esecuzione. Qual è la differenza tra loro?

nohupcattura il segnale di blocco (vedi man 7 signal) mentre la e commerciale non lo fa (tranne che la shell è configurata in questo modo o non viene inviata SIGHUPaffatto).

Normalmente, quando si esegue un comando usando &ed uscendo successivamente dalla shell, la shell termina il comando secondario con il segnale di blocco ( kill -SIGHUP <pid>). Questo può essere evitato usando nohup, in quanto cattura il segnale e lo ignora in modo che non raggiunga mai l'applicazione effettiva.

Nel caso in cui usi bash, puoi usare il comando shopt | grep huponper scoprire se la tua shell invia SIGHUP ai suoi processi figlio o meno. Se è spento, i processi non verranno chiusi, come sembra essere il tuo caso. Ulteriori informazioni su come bash termina le applicazioni sono disponibili qui .

Ci sono casi in cui nohupnon funziona, ad esempio quando il processo che si avvia riconnette il SIGHUPsegnale, come è il caso qui .

myprocess.out &eseguirà il processo in background usando una subshell. Se la shell corrente viene terminata (diciamo per logout), anche tutti i subshells vengono terminati in modo da terminare anche il processo in background. Il comando nohup ignora il HUPsegnale e quindi anche se la shell corrente è terminata, la subshell e myprocess.outcontinuerebbe a funzionare in background. Un'altra differenza è che &da solo non reindirizza lo stdout / stderr, quindi se ci sono output o errori, questi vengono visualizzati sul terminale. nohup d'altra parte reindirizzare lo stdout / stderr a nohup.outo $HOME/nohup.out.

Il più delle volte accediamo al server remoto usando ssh. Se si avvia uno script della shell e ci si disconnette, il processo viene interrotto. Nohup aiuta a continuare a eseguire lo script in background anche dopo aver effettuato il logout dalla shell.

Nohup command name &
eg: nohup sh script.sh &

Nohup cattura i segnali HUP. Nohup non inserisce automaticamente il processo in background. Dobbiamo dirlo esplicitamente usando &

L'uso della e commerciale (&) eseguirà il comando in un processo figlio (figlio della sessione bash corrente). Tuttavia, quando si esce dalla sessione, tutti i processi figlio verranno eliminati.

l'uso di nohup + e commerciale (&) farà la stessa cosa, tranne che al termine della sessione, il genitore del processo figlio verrà modificato in "1", che è il processo "init", preservando così il figlio dall'uccisione.

Correggimi se sbaglio

  nohup myprocess.out &

nohup rileva il segnale di blocco, il che significa che invierà un processo quando il terminale è chiuso.

 myprocess.out &

Il processo può essere eseguito ma verrà arrestato una volta chiuso il terminale.

nohup myprocess.out

Processo in grado di eseguire anche il terminale chiuso, ma è possibile arrestare il processo premendo ctrl+ znel terminale. Crt+ znon funziona se &esiste.

Il comando nohup è un'utilità di mascheramento del segnale e rileva il segnale di blocco. Dove come e commerciale non cattura i segnali di riaggancio. La shell termina il comando secondario con il segnale di riaggancio quando si esegue un comando usando & e si esce dalla shell. Questo può essere prevenuto usando nohup, poiché cattura il segnale. Il comando Nohup accetta il segnale di riaggancio che può essere inviato a un processo dal kernel e li blocca. Il comando Nohup è utile quando un utente desidera avviare la disconnessione dell'applicazione a esecuzione prolungata o chiudere la finestra in cui è stato avviato il processo. Una di queste azioni richiede normalmente al kernel di riagganciare sull'applicazione, ma un wrapper nohup consentirà al processo di continuare. L'uso della e commerciale eseguirà il comando in un processo figlio e questo figlio della sessione bash corrente. Quando esci dalla sessione, tutti i processi figlio di quel processo verranno uccisi. La e commerciale si riferisce al controllo del lavoro per la shell attiva. Ciò è utile per eseguire un processo in una sessione in background.

Ci sono molti casi in cui piccole differenze tra gli ambienti possono morderti. Questo è quello in cui mi sono imbattuto di recente. Qual è la differenza tra questi due comandi?

1 ~ $ nohup myprocess.out &
2 ~ $ myprocess.out &

La risposta è la stessa del solito - dipende.

nohup cattura il segnale di hangup mentre la e commerciale no.

Qual è il segnale di riaggancio?

SIGHUP - Hangup rilevato sul terminale di controllo o morte del processo di controllo (valore: 1).

Normalmente, quando si esegue un comando utilizzando & e successivamente si esce dalla shell, la shell termina il comando secondario con il segnale di blocco (come kill -SIGHUP $ PID). Questo può essere evitato usando nohup, in quanto cattura il segnale e lo ignora in modo che non raggiunga mai l'applicazione effettiva.

Bene, ma come in questo caso ci sono sempre dei "ma". Non vi è alcuna differenza tra questi metodi di avvio quando la shell è configurata in un modo in cui non invia affatto SIGHUP.

Nel caso in cui si usi bash, è possibile utilizzare il comando specificato di seguito per scoprire se la shell invia SIGHUP ai suoi processi figlio o meno:

~ $ shopt | grep hupon

E inoltre - ci sono casi in cui nohup non funziona. Ad esempio, quando il processo avviato riconnette il segnale NOHUP (viene eseguito all'interno, a livello di codice dell'applicazione).

Nel caso descritto, la mancanza di differenze mi ha colpito quando all'interno di uno script di avvio del servizio personalizzato è stata effettuata una chiamata a un secondo script che imposta e avvia l'applicazione corretta senza un comando nohup.

In un ambiente Linux tutto ha funzionato senza problemi, in un secondo l'applicazione si è chiusa non appena è uscito il secondo script (rilevando quel caso, ovviamente mi ci è voluto molto più tempo di quello che potresti pensare: stuck_out_tongue :).

Dopo aver aggiunto nohup come metodo di avvio al secondo script, l'applicazione continua a funzionare anche se gli script usciranno e questo comportamento diventerà coerente in entrambi gli ambienti.