Cosa succede ai lavori in background dopo essere usciti dalla shell?

Dalla mia comprensione, di posti di lavoro sono condotte iniziate da un certo guscio e si possono gestire questi lavori ( fg, bg, Ctrl-Z) da dentro questo guscio. Un lavoro può essere composto da più processi / comandi.

La mia domanda è: cosa succede a questi lavori quando esce l'originale, contenente shell? Supponiamo che huponexit non sia impostato in modo che i processi in background continuino a essere eseguiti dopo la chiusura della shell.

Supponiamo di aver fatto:

$ run.sh | grep 'abc' &
[1] job_id

Quindi esco da questa shell. Entro in una nuova shell e corro jobse ovviamente non vedo nulla. Ma che posso fare ps aux | grep run.she vedere questo processo in esecuzione e io anche fare ps aux | grep grepe vedere il processo per grep 'abc'l'esecuzione troppo.

C'è un modo per ottenere l'ID lavoro per l'intera pipeline in modo da poterlo uccidere in una volta sola o devo uccidere tutti i processi separatamente da un'altra shell una volta uscita dalla shell originale? (Ho provato quest'ultimo e funziona, ma sembra una seccatura tenere traccia di tutti i processi.)

Quando la shell esce, potrebbe inviare il segnale HUP ai lavori in background e questo potrebbe farli uscire. Il segnale SIGHUP viene inviato solo se la shell stessa riceve un SIGHUP, vale a dire solo se il terminale scompare (ad es. Perché il processo di emulazione del terminale si interrompe) e non se si esce normalmente dalla shell (con il exitcomando incorporato o digitando Ctrl+ D). Vedi In quali casi SIGHUP non viene inviato a un lavoro quando ti disconnetti? e c'è qualche variante UNIX su cui un processo figlio muore con il suo genitore? per ulteriori dettagli. In bash, puoi impostare l' huponexitopzione per inviare SIGHUP anche a lavori in background su un'uscita normale. In ksh, bash e zsh, chiamandodisownsu un lavoro lo rimuove dall'elenco dei lavori a cui inviare SIGHUP. Un processo che riceve SIGHUP può ignorare o catturare il segnale e quindi non morirà. L'uso nohupdurante l'esecuzione di un programma lo rende immune a SIGHUP.

Se il processo non viene interrotto a causa di un possibile SIGHUP, rimane indietro. Non è rimasto nulla per metterlo in relazione con i numeri dei lavori nella shell.

Il processo potrebbe comunque interrompersi se tenta di accedere al terminale ma il terminale non esiste più. Dipende da come il programma reagisce a un terminale inesistente.

Se il lavoro contiene più processi (ad es. Una pipeline), tutti questi processi si trovano in un gruppo di processi . I gruppi di processi sono stati inventati proprio per catturare l'idea di un lavoro shell composto da più processi correlati. Puoi vedere i processi raggruppati per gruppo di processo visualizzando il loro ID gruppo di processi (PGID - normalmente l'ID di processo del primo processo nel gruppo), ad esempio con ps lsotto Linux o qualcosa di simile in modo ps -o pid,pgid,tty,etime,commportabile.

Puoi uccidere tutti i processi in un gruppo passando un argomento negativo a kill. Ad esempio, se hai determinato che il PGID per la pipeline che vuoi uccidere è 1234, puoi ucciderlo con

kill -TERM -1234

In generale corrono ancora, ma dovresti usare nohup, se hai dimenticato o cambiato idea usa disown.

mike@mike-laptop4:~$ sleep 500
^Z
[1]+  Stopped                 sleep 500
mike@mike-laptop4:~$ bg
[1]+ sleep 500 &
mike@mike-laptop4:~$ jobs
[1]+  Running                 sleep 500 &
mike@mike-laptop4:~$ disown %1
mike@mike-laptop4:~$ jobs
mike@mike-laptop4:~$