Perché il processo in background nohup viene ucciso?

10

Ho provato ad avviare uno script di shell tramite una sessione remota, che avvia un processo in background utilizzando il comando.

nohup python3 run.py > nohup.out &

Quando la sessione remota viene chiusa, il processo viene interrotto con il messaggio:

Segnale rilevato SIGHUP

SIGHUP catturato ma non demone. Uscita.

Non capisco; perché il processo viene ucciso quando è stato avviato in background usando nohup & ?

background-process  nohup 
— Mani più richieste
fonte
1
Ero confuso da tutto il comportamento imprevisto del controllo del lavoro della shell. Ora uso tmuxe ignoro nohupo disconosco completamente o completamente l'attività in background.
— Siyuan Ren,

Risposte:

10

Il tuo programma Python viene annullato nohup.

nohupignora il segnale di riaggancio con SIG_IGNe quindi carica a catena il programma nello stesso processo.

Il programma Python ripristina prontamente la gestione del segnale per il segnale di blocco, installando il proprio gestore di segnale. Quel gestore controlla una funzione interna (che non è progettata molto bene, essendo basata su alcuni presupposti imperfetti, se è quello che ho visto) e decide che il modo appropriato di agire alla ricezione di un segnale di blocco è stampare quel messaggio ed esci.

Il tuo programma Python in base alla progettazione non è nohuputilizzabile. Su un sistema con una shell di controllo lavoro e una semantica di sessione / lavoro POSIX, è necessario eseguire disownil lavoro in modo che la shell non lo sappia mai per inviargli un segnale di blocco.

(Anche questo non è sufficiente sui sistemi operativi systemd. Poiché le persone systemd hanno fatto un po 'un orecchio del loro meccanismo di sessione di accesso nello spazio utente, è inoltre necessario assicurarsi che il meccanismo di systemd che segnali l'arresto del sistema, piuttosto che il riaggancio, a anche le sessioni di accesso ad ogni disconnessione non vengono avviate.)

Ulteriori letture

— JdeBP
fonte
3
È il loro programma Python che lo fa, o è l'interprete Python (/ ambiente run-time) che lo fa silenziosamente alle loro spalle?
— ilkkachu,
Inoltre, su Mac OS, il logout da una sessione ssh uccide i lavori shell, anche quando si inizia a utilizzare nohup; non ho trovato un rimedio per questo
— imhotap
Bene, se il problema è il gestore del segnale, l'OP potrebbe semplicemente cambiare il gestore del segnale in un gestore che non uccide il processo. Questo dovrebbe funzionare indipendentemente da chi installa tale gestore di segnale. Vorrei aggiungere riguardo a ssh: a volte, anche se il processo è mantenuto in vita, potrebbe avere problemi. Un paio di anni fa ho perso un bel po 'di tempo cercando di capire alcuni errori di autorizzazione e, alla fine, il colpevole era Kerberos: quando la sessione SSH era chiusa i token erano scaduti, quindi ho dovuto creare nuovi token da utilizzare invece di quelli della sessione ssh.
— Bakuriu,
@JdeBP Ho provato setsid nohup python3 run.py > nohup.out &, setsid ha risolto questo problema. È un approccio adeguato?
— Mostwanted Mani
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.