Se avvio un processo in background e quindi esco, continuerà a essere eseguito?

29

Chiedendolo dopo una discussione prolungata con un collega, vorrei davvero un chiarimento qui.

Avvio di un processo in background, aggiungendo " &" alla riga di comando o interrompendolo con CTRL-Ze riprendendolo in background con " bg". Quindi esco.

Che succede?

Eravamo abbastanza sicuri che avrebbe dovuto essere ucciso da un SIGHUP, ma ciò non è accaduto; dopo aver effettuato nuovamente l'accesso, il processo è stato felicemente in esecuzione e ha pstreedimostrato che è stato "adottato" da init.

È questo il comportamento previsto?

Ma allora, se lo è, qual è lo nohupscopo del comando? Sembra che il processo non verrà comunque ucciso, con o senza di esso ...

Modifica 1

Alcuni dettagli in più:

Il comando è stato avviato da una sessione SSH, non dalla console fisica.
Il comando è stato lanciato senza nohup e / o &; è stato quindi sospeso con CTRL-Ze ripreso in background con bg.
La sessione SSH non è caduta. Si è verificato un logout effettivo ( exitcomando " ").
Il processo è stato un'operazione di scpcopia dei file.
Al login di nuovo, ha pstreemostrato il processo in esecuzione e di essere figlio di init.

Modifica 2

Per affermare la domanda in modo più chiaro: mettere un processo in background (usando &o bg) lo farà ignorare SIGHUP, proprio come fa il nohupcomando?

Modifica 3

Ho provato a inviare manualmente un SIGHUPa scp: è uscito, quindi sicuramente non ignora il segnale.

Quindi ho provato di nuovo a lanciarlo, mettendolo in background e disconnettendomi: è stato "adottato" da inite continuato a funzionare, e l'ho trovato lì quando ho riconnesso.

Sono abbastanza perplesso ora. Sembra che non sia SIGHUPstato inviato affatto dopo la disconnessione.

— Massimo
fonte

Non ho visto alcuna menzione di I / O della console, che farà scattare anche le cose. Hai deviato cose, ad esempio 1>/dev/null 2>&1per bash, ecc.?

— Avery Payne,

No, non l'ho fatto. Naturalmente SCP non ha richiesto input standard ... e l'output standard non sembra essere un problema.

— Massimo,

Se la shell viene eseguita o meno come shell di accesso modifica le prestazioni, che può essere il caso qui.

— Warner,

Fatto altri test; L'ho riassunto qui: serverfault.com/questions/117152 .

— Massimo,

20

Risposta trovata

Per BASH, questo dipende huponexitdall'opzione shell, che può essere visualizzata e / o impostata usando il shoptcomando integrato .

Sembra che questa opzione sia disattivata per impostazione predefinita, almeno sui sistemi basati su RedHat.

Maggiori informazioni sulla pagina man di BASH :

La shell esce di default al ricevimento di un SIGHUP. Prima di uscire, una shell interattiva rinvia SIGHUP a tutti i lavori, in esecuzione o arrestati. I lavori interrotti vengono inviati a SIGCONT per garantire che ricevano il SIGHUP. Per impedire alla shell di inviare il segnale a un particolare lavoro, è necessario rimuoverlo dalla tabella dei lavori con il comando incorporato disown (vedere COMANDI INCORPORATI SHELL di seguito) o contrassegnato per non ricevere SIGHUP usando disown -h.

Se l'opzione shell huponexit è stata impostata con shopt, bash invia un SIGHUP a tutti i lavori quando esce una shell di login interattiva.

— Massimo
fonte

2

È uno stupido default, ma le mie viscere mi dicono che è un errore RH piuttosto che bash. A proposito, con zsh puoi usare &! come scorciatoia da rinnegare e i processi biforcuti con & get get sighup.

— Jürgen Strobel,

7

Sono d'accordo con Warner e voglio solo aggiungere che puoi impedire alla shell di inviare SIGHUP con il comando "disown" incorporato. La pagina man di bash contiene una buona descrizione.

— Kim
fonte

4

È possibile utilizzare il comando nohup per avviare il comando e reindirizzare l'output in un file di output nohup. Dalla pagina man nohup:

nohup - run a command immune to hangups, with output to a non-tty

L'altra opzione è usare il comando schermo . Il vantaggio dell'uso dello schermo è che è possibile riconnettersi al processo in un secondo momento.

— Jim
fonte

Perché i downvotes? L'uso di nohup e dello schermo sono modi perfettamente accettabili per evitare di uccidere un processo al logout. Ce ne sono altri, ma entrambi funzionano. Qual è l'accordo?

— Jim,

2

Penso che sia un ottimo punto, ma il Q riguarda il motivo per cui i suoi processi non vengono uccisi, NON "come impedire che vengano uccisi".

— CarpeNoctem,

2

Quando si esegue il fork di un processo in background, rimarrà comunque il processo figlio dalla shell che lo esegue.

Tutti i processi figlio in esecuzione in una shell vengono inviati un SIGHUP all'uscita. Le prestazioni variano leggermente a seconda della situazione esatta, che è descritta dettagliatamente nella manpage di bash. Altre shell hanno probabilmente descrizioni simili.

Apache e altri demoni in genere ricaricano la configurazione su SIGHUP. Le utility per lo spazio utente spesso muoiono. Le prestazioni dell'applicazione collegate ai segnali possono essere uniche per l'applicazione.

— Ammonitore
fonte

Quindi il processo dovrebbe aver appena ricevuto un SIGHUP in questo caso, giusto? Forse l'ho semplicemente ignorato, controllerò.

— Massimo

Si, esattamente. Questo è quello che credo sia la situazione. Se dubiti davvero delle prestazioni documentate, potresti tagliare un piccolo script per intrappolare il segnale e registrarlo.

— Warner,

0

Qual è stato il processo? Le prestazioni descritte nel precedente post 1 erano accurate.

Alcune funzioni e processi di script possono intercettare i segnali. mentre i loop possono scappare come un matto.

Vedere:

La sessione SSH viene interrotta: il comando continua l'esecuzione?

Modifica 1 alle 16:22

Dalla manpage di bash:

The shell exits by default upon receipt of a SIGHUP.   Before  exiting,
an  interactive  shell  resends  the  SIGHUP  to  all  jobs, running or
topped.

La ricerca iniziale 1 sta dimostrando che OpenSSH probabilmente ignora SIGHUP, forse più segnali.

— Ammonitore
fonte

Quel post mi ha davvero ispirato a porre la domanda. Per i dettagli, vedi modifica sopra.

— Massimo

2

Le risposte nell'altro thread ti fanno sembrare che devi leggere il comando SCP che stai usando e vedere come risponde a SIGHUP

— mfinni

E 'nohup' è per i comandi che sai che moriranno con un SIGHUP e non vuoi che lo facciano, immagino.

— mfinni,

La pagina man non lo dice; Proverò ad ucciderlo -HUP domani ...

— Massimo

-1

Se non hai avviato il comando tramite uno strumento simile screen, quindi al termine della sessione, esegui tutti i lavori / attività associati a quella sessione.

— conigliera
fonte

È esattamente quello che stavo pensando, tranne ... semplicemente non l'hanno fatto.

— Massimo

hanno ogni volta che ho fatto quello che hai descritto ... forse dipende dalla shell che usi?

— Warren,

-1 Non lo fanno; la risposta non è così semplice. Ho appena testato un semplice script di shell che ho iniziato in background; ha eseguito il loop e ha inviato l'output a un file temporaneo. Continuò a funzionare dopo che sono uscito dal terminale (come visto dal tail -ffile temporaneo. Questo su una macchina CentOS 7.1 che utilizza bash.

— Mike S

@MikeS - per favore dimostralo. Non ho mai assistito al comportamento che descrivi

— warren,

@warren - Vedi la mia risposta a serverfault.com/questions/117152/… . Nota che un certo numero di persone afferma un comportamento diverso da quello che descrivi; infatti, Massimo ha pubblicato proprio perché il suo processo è continuato.

— Mike S,