Vorrei conoscere lo scopo di nohup
in questi giorni .
Lo chiedo perché ho letto questo
Nohup è l'abbreviazione di "No Hangups". Non è un comando che esegui da solo. Nohup è un comando supplementare che dice al sistema Linux di non interrompere un altro comando una volta avviato. Ciò significa che continuerà a funzionare fino al termine, anche se l'utente che l'ha avviato si disconnette. La sintassi per nohup è semplice e assomiglia a questa:
nohup sh tuo-script.sh &
Notare la "&" alla fine del comando. Ciò sposta il comando in background, liberando il terminale su cui stai lavorando.
Nohup funziona con quasi tutti i comandi che esegui nel terminale. Può essere eseguito con script personalizzati, comandi di sistema standard e utilità da riga di comando.
Con l'utilizzo di distribuzioni Linux come SLES 11.4 o RHEL/CentOS 7.x, posso
- accesso remoto a Linux tramite la rete tramite SSH
- esegui il semplice programma qui sotto, o qualsiasi altro, facendo
./a.out &
- disconnettersi da linux; digita exit nel terminale SSH di mastice
- il mio programma di esempio di seguito, o qualsiasi altro, inclusi gli script di shell bash, csh o tcsh, viene eseguito fino al completamento senza la necessità di
nohup
- digitando exit in stucco per chiudere una sessione SSH, penserei che si qualifichi come logout?
C'è qualche scopo o valore con nouhup
oggi? È un kernel>=3.x cosa? Per quanto tempo posso ricordare (kernel>=2.6) non ho mai usato nohup
e usa sempre &
senza problemi.
Qualcuno può darmi uno scenario pratico in cui nohup
verrebbe utilizzato?
#include <stdlib.h>
#include <stdio.h>
/*
sample C code, to print numbers to a file named zz.tmp
the numbers 0 to 29 over 30 seconds
*/
int main ( int argc, char *argv[] )
{
FILE *fp;
int i;
i = 0;
fp = fopen("zz.tmp", "w" );
while ( i < 30 )
{
fprintf( fp, "%dn", i++ );
sleep( 1 );
}
fclose( fp );
return 0;
}
mysleep.sh
#!/bin/bash
sleep 1000
Su Centos 7.7, accedi al PC optiplex con tastiera e mouse, il mio account è bash. Faccio nohup ./mysleep.sh
e poi control-z . Quando si digita jobs
Vedo [1]+ Stopped nohup ./mysleep.sh
A ps -ef | grep mysleep
mostra che l'id del processo esiste, ma se chiudo la finestra del terminale tramite la X nell'angolo in alto a destra, quel processo scompare, quindi sembra nohup
non funziona?
Risposta accettata:
accesso remoto a linux sulla rete tramite SSH … disconnettersi da linux; digita exit
nel terminale SSH dello stucco
Qualcuno può darmi uno scenario pratico in cui nohup
verrebbe utilizzato?
Sicuro. Supponendo che la tua shell sia bash (vedi sotto perché), invece di digitare exit
o ^D
, digita ~.
all'inizio di una riga, che causerà la disconnessione del client ssh :
$ ssh localhost
ssh$ sleep 3600 &
[1] 5765
ssh$ ~.
ssh$ Connection to localhost closed.
$ ps 5765
PID TTY STAT TIME COMMAND
Puoi usare il tuo programma invece di sleep
; e invece di disconnettersi tramite ~.
, puoi uccidere il tuo client ssh o mandare in crash la macchina su cui gira. Vuoi che il tuo processo sopravviva a questo? Usa nohup
😉
L'interruzione della connessione causerà l'uscita del processo del server che gestisce l'altra estremità, facendo sì che il kernel (qualsiasi kernel Unix/Linux) distrugga lo pseudo-terminale che ssh aveva creato e invii un SIGHUP
segnala al leader della sessione (la shell bash), che secondo il manuale di bash:
La shell esce per impostazione predefinita alla ricezione di un SIGHUP
. Prima di uscire,
una shell interattiva invia nuovamente il SIGHUP
a tutti i lavori, in esecuzione o
interrotti. I lavori interrotti vengono inviati SIGCONT
per assicurarsi che ricevano il SIGHUP
.
Molte persone confondono questa funzione bash con a) il normale controllo del lavoro implementato dal kernel, che invierà solo un SIGCONT
/SIGHUP
accoppiare a arrestato , non alla corsa lavori [1] e b) un'altra funzione bash (shopt -s huponexit
) che provoca un accesso bash shell per inviare un SIGHUP
ai suoi lavori anche quando esce normalmente (es. tramite exit
).
[1] un fermato job è un job (=gruppo di processi) che contiene almeno un processo interrotto. Un processo viene interrotto come effetto dell'azione predefinita di un segnale come SIGTSTP
, SIGSTOP
, SIGTTIN
o SIGTTOU
. Processi che sono "inattivi" su una chiamata di sistema di blocco come read
, nanosleep
, select
, etc non sono considerati fermi, ma in esecuzione.
Perché nohup
potrebbe non essere sempre d'aiuto
nohup
imposta semplicemente la disposizione di SIGHUP
ignorare e fare alcuni reindirizzamenti, non garantisce che il processo non verrà interrotto in altri modi.
a) Se il nohup ..
il lavoro è interrotto , una bash interattiva gli invierà anche un SIGTERM
segnale, non solo un SIGHUP
/SIGCONT
coppia:
Se viene effettuato un tentativo di uscire da bash mentre i lavori sono interrotti […] la shell stampa un messaggio di avviso […] Se viene effettuato un secondo tentativo di uscire senza un comando intermedio, la shell non stampa un altro avviso e tutti i lavori interrotti vengono terminato .
[terminato =ha inviato un SIGTERM
segnale; questa è un'altra funzionalità di ksh/bash, non presente in tutte le shell]
Tutto questo può essere aggirato con semplici trucchi come i double fork e creando una nuova sessione con setsid(1)
, ma
b) systemd
può anche "ripulire" una sessione disconnessa uccidendo forzatamente (con SIGTERM
seguito da SIGKILL
) eventuali processi rimanenti se i suoi KillUserProcesses
l'impostazione è attiva, che è l'impostazione predefinita in alcune distribuzioni.