Perché alcuni programmi in esecuzione da Terminal usando '&' si chiudono quando Terminal lo fa e altri no?


27

Mi stavo solo chiedendo, ad esempio quando lancio qtoxcon:

qtox &

E poi chiudi Terminal, si qtoxchiude con esso. Tuttavia quando si esegue etherapeutilizzando:

sudo etherape &

Il Terminale di chiusura non si chiude né causa problemi a Etherape. E tra le diverse applicazioni esiste un comportamento diverso, alcuni vicini quando Terminal lo fa, altri no, come mai? Perché alcuni chiudono quando altri no? Sto eseguendo Ubuntu GNOME 15.10 con GNOME 3.18.


1
Potrebbe essere che apri un terminale, esegui qtox, chiudi il terminale, tutto !! Ma il secondo ti fa aprire il terminale, sudo esegue etherape, ora chiudi il terminale, ma sudo continua a funzionare fino a quando sudo si chiude?
Ken Mollerup,

Bene, se non vuoi qtoxuscire quando chiudi il terminale puoi sempre eseguirlo nohup qtox &.
Terrance

@Terrance: Beh, in questa domanda stavo chiedendo specificamente perché, non come ... Sarebbe la mia altra domanda ... :)

1
@ParanoidPanda Ah, buon punto. Colpa mia. =)
Terrance

Risposte:


36

Quando si chiude un terminale, il terminale invia un segnale SIGHUP alla shell; la shell, a sua volta, invia un segnale SIGHUP a tutti i suoi gruppi di processi figlio, che includono gruppi di processi in background;

Il modo in cui ogni singolo processo reagirà al segnale dipende interamente dal processo: se il processo non ha definito un gestore per il segnale e ha detto al kernel (tramite alcuni syscall come signal()o sigaction()) che desidera gestirlo, il kernel esegue il gestore predefinito per il segnale, che nel caso di un segnale SIGHUP consiste nel terminare il processo.

Tuttavia, quando si esegue un comando con sudo, l'UID del sudoprocesso e il relativo processo figlio sono impostati su 0(root); in generale, a meno che l'UID del processo che invia il segnale sia 0(root) o uguale al processo di destinazione, il kernel ignora il segnale (cioè: un processo non può inviare segnali a un processo di proprietà di un altro utente, a meno che il processo l'invio del segnale è di proprietà di root); ecco perché un processo eseguito dall'utente come l'istanza di Bash eseguita dal terminale non può SIGHUP un sudoprocesso e, in definitiva, chiudere un terminale non influenza un processo iniziato con sudo.


7
Ed è per questo che abbiamo bisogno nohupdi fronte a quei comandi che si chiudono con SIGHUP :) Upgoated
Sergiy Kolodyazhnyy

9
Penso che non ci sia nulla di magico sudo. sudoesegue semplicemente il comando come un altro utente e non è possibile inviare segnali ai processi di altri utenti. Vedere man 2 kill.
el.pescado,

@ el.pescado Quindi c'è sudouna specie di povero nohup?
Hagen von Eitzen,

7
@HagenvonEitzen Se vuoi, ma mi trattengo fortemente dall'eseguire un comando che non richiede sudocon il sudosuo nohupeffetto collaterale, considerato tutti gli altri aspetti negativi.
kos,

2
@Serg non abbiamo bisogno nohup, crea nohup.outfile non necessari dopo di esso. Usa piuttosto il disowncomando incorporato.
Ruslan,
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.