Risposte:
Cosa c'è di meglio, un pesce o una bicicletta? nohup
e exec
fare cose diverse.
exec
sostituisce la shell con un altro programma. L'uso exec
in un semplice lavoro in background non è utile: exec myprogram; more stuff
sostituisce la shell con myprogram
e quindi non funziona more stuff
, diversamente da myprogram; more stuff
come viene eseguito more stuff
quando myprogram
termina; ma exec myprogram & more stuff
inizia myprogram
in background e poi viene eseguito more stuff
, proprio come myprogram & more stuff
.
nohup
esegue il programma specifico con il segnale SIGHUP ignorato. Quando un terminale è chiuso, il kernel invia SIGHUP al processo di controllo in quel terminale (cioè la shell). La shell a sua volta invia SIGHUP a tutti i lavori in esecuzione in background. L'esecuzione di un lavoro nohup
impedisce che venga ucciso in questo modo se il terminale muore (cosa che accade ad es. Se si è effettuato l'accesso in remoto e la connessione si interrompe o se si chiude l'emulatore di terminale).
nohup
reindirizza anche l'output del programma sul file nohup.out
. Questo evita che il programma muoia perché non è in grado di scrivere sul suo output o output di errore. Si noti che nohup
non reindirizza l'input. Per disconnettere completamente un programma dal terminale in cui è stato avviato, utilizzare
nohup myprogram </dev/null >myprogram.log 2>&1 &
exec firefox
, la shell non è più in esecuzione: è stata sostituita da firefox
. Puoi pensare di exec
combinare l'uscita da un programma e avviarne uno nuovo, mantenendo lo stesso ID processo. Il terminale continua a funzionare perché nulla gli ha detto di fermarsi. Quando successivamente esci da Firefox, il firefox
processo termina. Il terminale nota che il suo processo figlio è uscito e quindi a sua volta esce.
exec &
=> esegue un processo come processo in background in modo da poter continuare a utilizzare lo stesso terminale per altri lavori.
nohup
=> evita tutti i SIGHUP (segnale di terminazione) e continua l'esecuzione anche se il terminale è chiuso.
exec
il processo muore quando SIGHUP
viene ricevuto un, ma il nohup
processo continua.
exec
sostituisce il processo in esecuzione, ma ciò non sembra accadere quando si usa &
in background il comando exec'd. Né in bash né in zsh.
exec smth &
è lo stesso di (exec smth) &
quello che sta succedendo?
(exec smth) &
. Ma non mi aspetto che sia lo stesso - mi aspetto che sia un errore di sintassi, come puoi eseguire un processo (sostituendo te stesso) e quindi in background il processo exec? Non sei più lì per farlo.
Il comando integrato exec <command>
della shell sostituisce la shell con <command>
, nessun nuovo processo, nessun nuovo PID viene creato. Dopo il completamento, <command>
normalmente il tuo terminale si chiuderà. Eseguendolo prima in background, viene creata una subshell, che quindi viene immediatamente sostituita da <command>
.
Il nohup <command>
comando verrà eseguito <command>
ma si immetterà nei blocchi (kill -s 1), quindi non verrà terminato quando la shell, il terminale da cui è stato avviato, viene chiusa. Eseguendolo prima in background, viene creata una subshell e il comando viene eseguito in background, restituendo al prompt.
Nello scripting l'effetto immediato è più o meno lo stesso, <command>
viene avviato dallo script e lo script continuerà senza attendere <command>
l'avvio, l'invio dell'output o il completamento.
script.sh &
o exec script.sh &
. In entrambi i casi il comando viene eseguito in un processo figlio, non sostituisce il processo di chiamata, vedere: paste.alacon.org/44474 (troppo tempo per copiarlo qui in un commento ...). Che cosa sto facendo di sbagliato?
Non puoi confrontarti nohup
con exec
. Quando si esegue un eseguibile con nohup
, il processo non verrà interrotto al logout (sessione ssh); di solito nohup
viene utilizzato nice
per eseguire processi con una priorità inferiore. Il HUP
segnale è, per convenzione, il modo in cui un terminale avverte processi dipendenti di logout