Sfondo, zombi, demone e senza ctty: questi concetti sono collegati?


8

Come questi concetti di processo sono legati insieme - background, zombie, daemone without controlling terminal?

Sento che sono in qualche modo vicini, soprattutto attraverso il concetto di controlling terminal, ma non ho ancora molte informazioni per raccontare una storia, come se dovessi spiegare qualcosa a un bambino che legge un articolo su Linux senza mentire troppo.

AGGIORNAMENTO N. 1: Ad esempio (non so se sia vero)

  • background- zombie- Il processo in primo piano non può diventare zombie, perché zombieè un processo in background che è stato lasciato senza un genitore
  • daemon- without ctty- tutti daemonsfunzionano senza ctty, ma non tutti i processi senza lo cttysonodaemons
  • background- daemon- a background processpuò essere recuperato per essere eseguito nuovamente in modo interattivo,daemon is not
  • zombie- without ctty- zombieè indifferente se vi è cttyattaccato o no
  • background- without ctty- processesinviati sullo sfondo mentre hanno ctty, e diventano demoni o muoiono se cttyviene preso da loro

Un processo in primo piano può certamente essere uno zombi, anche se di solito non per un periodo di tempo apprezzabile - il solito modo per una shell (o un altro programma) di eseguire un sottoprocesso in primo piano è fork()disattivare una copia di te stesso, usarlo exec()in quella copia per sostituirlo con ciò che si desidera eseguire e utilizzare wait()nell'istanza originale del programma (non nella copia eseguita exec()). Nel brevissimo periodo tra il momento in cui il bambino esce e il momento in cui wait()viene ripristinato lo stato di uscita (rimuovendolo dalla tabella dei processi e restituendolo al chiamante), si ha uno zombi.
Charles Duffy,

@CharlesDuffy è possibile inviare il genitore in background lasciando il bambino in esecuzione in primo piano?
Anatoly Techtonik,

Nel tipico controllo del lavoro, la shell non sa nemmeno che il nipote è separato dal suo figlio diretto; sta solo aspettando che suo figlio esca, e se il bambino sta aspettando l'uscita di un nipote, allora è affar suo. Vale a dire: dal punto di vista della shell che ha generato il genitore, ha a che fare solo con un'unità.
Charles Duffy,

Risposte:


10

In breve, oltre a collegamenti.

zombie

un processo che è uscito / terminato, ma il cui genitore non ha ancora riconosciuto la terminazione (utilizzando le wait()chiamate di sistema). I processi morti vengono mantenuti nella tabella dei processi in modo che i loro genitori possano essere informati che il loro figlio del processo figlio sta uscendo e del loro stato di uscita. Di solito un programma che biforca i bambini leggerà anche il loro stato di uscita quando escono, quindi vedrai gli zombi solo se il genitore è fermo o difettoso.

Vedere:

terminale di controllo, sessione, primo piano, sfondo

Questi sono correlati al controllo dei lavori nel contesto di una shell in esecuzione su un terminale. Un utente accede, viene avviata una sessione, legata a un terminale (il terminale di controllo) e viene avviata una shell. La shell quindi esegue i processi e li invia in primo piano e in background come desidera l'utente (utilizzando &all'avvio del processo, interrompendolo con ^Z, utilizzando fge bg). I processi in background vengono interrotti se si legge o si scrive dal terminale; i processi in primo piano ricevono il segnale di interruzione se ^Cviene colpito sul terminale. (È il driver terminale del kernel che gestisce quei segnali, la shell controlla quale processo (gruppo) viene inviato in primo piano o in background.

Vedere:

demone

Un processo in esecuzione come demone è in genere qualcosa che non dovrebbe essere legato a nessun terminale particolare (o una sessione di accesso o una shell). Non dovrebbe avere un terminale di controllo, in modo che non riceva segnali se il terminale si chiude e di solito non si vuole che faccia l'I / O su un terminale. L'avvio di un demone dalla riga di comando richiede l'interruzione di tutti i legami con il terminale, ovvero l'avvio di una nuova sessione (nel senso del controllo del lavoro, sopra) per sbarazzarsi del terminale di controllo e chiusura degli handle di file sul terminale. Ovviamente qualcosa che è iniziato da init, systemd o simili al di fuori di una sessione di accesso non avrebbe questi legami per cominciare.

Dato che un demone non ha un terminale di controllo, non è soggetto al controllo del lavoro, e non essere applicabile in "primo piano" o "sfondo" nel senso del controllo del lavoro. Inoltre, i demoni di solito ricorrono ai genitori initche li puliscono quando escono, quindi di solito non li vedi come zombi.

Vedere:


4

Lo zombi non è realmente imparentato con gli altri; è semplicemente un processo che è terminato, ma il suo processo padre non ha ancora letto il suo stato di uscita con waitpid()o simile. Non dovresti vederli a meno che un processo non sia difettoso o interrotto.

Un demone è un programma che funziona senza un terminale di controllo. In genere quando si esegue il programma, esso fork()sstesso e il genitore esce in modo che la shell pensi che il comando sia terminato, e il processo figlio si stacca dal terminale ed esce dalla sessione di login. Da quando è terminato il processo principale, l'ID del processo principale diventa 1, che è tradizionalmente il initprogramma o al giorno d'oggi systemd. Questo processo si assicura di raccogliere i suoi figli quando muoiono in modo da non finire invaso dagli zombi.

Un processo può essere associato a un terminale di controllo , che è da dove normalmente riceve il suo input e invia il suo output a. Il terminale può anche inviare segnali ai processi ad esso collegati e identifica un gruppo di processi come gruppo in primo piano . I processi che si trovano nel gruppo di primo piano possono leggere l'input dal terminale e vengono inviati segnali SIGINT e SIGSUSP quando si preme Ctrl-C e Ctrl-Z. Qualsiasi processo non nel gruppo in primo piano che tenta di leggere dal terminale viene sospeso con SIGTSTP.

La shell crea diversi gruppi di processi per ciascuno dei comandi della pipeline che gli viene richiesto di eseguire e sposta quale è il gruppo in primo piano per spostare i lavori tra primo piano e sfondo. Quando si esegue un comando, normalmente la shell crea un nuovo gruppo di processi e trasforma quel gruppo in primo piano . Se lo suffissi con un &quindi la shell lascia semplicemente il gruppo in primo piano dov'era e quindi il nuovo gruppo è in background. Premendo Ctrl-Z si invia SIGSUSP al gruppo di primo piano, causando la sospensione della maggior parte dei comandi, ma invece di sospendere, la shell cambia di nuovo il gruppo di primo piano attivo su se stesso in modo da poter richiedere un nuovo comando.

Il bgcomando invia SIGCONT a un gruppo di processi in modo che possa riprendere l'esecuzione in background dopo essere stato sospeso con SIGSUSP. fgcambia il gruppo in primo piano in uno dei gruppi esistenti già in esecuzione in background, portandolo in primo piano.


4

Ok, ecco la mia spiegazione con un'enfasi sulle differenze tra questi tipi di processi (breve ma informativo):

  • zombie- processo che è appena terminato (ha terminato l'esecuzione) ma ha ancora una voce in una tabella dei processi. Nota : il processo zombie ha ancora un genitore e di solito l'intero punto della sua esistenza è quello di far sapere a quel processo genitore il risultato dell'esecuzione del bambino (codice di uscita ecc.).
  • disowned process(senza controllare il terminale) - processo che è stato esplicitamente disown"modificato dall'utente" o progettato per essere staccato da un albero dei processi padre. Sarebbe comunque in esecuzione anche se il processo padre avrebbe terminato l'esecuzione. Ad esempio, l'utente è sshpassato a una macchina remota, ha avviato qualcosa come un server Web, quindi eseguito disownsu di esso ed è uscito dalla sshsessione. Il processo sarebbe ancora in esecuzione poiché non fa più parte di un albero dei processi padre. Il processo può anche essere ignorato eseguendolo con nohup.
  • background process- viene eseguito in background - non divide l'output in tty di un utente. O è stato eseguito con &alla fine, o biforcandosi su uno sfondo di progettazione. Un'altra opzione per inviare un processo a uno sfondo è avviarlo e premere ctrl+z. Tuttavia, quando termina il processo genitore, anche il figlio in esecuzione in background terminerebbe ( nota di @psusi - il fatto precedente è vero solo con i processi avviati da un terminale dall'utente; altrimenti il ​​processo figlio diventa un 'orphant' e ottiene un processo init (pid 1) come genitore).
    • daemon- molto simile al processo in background. Funziona anche in background ma molto probabilmente è stato biforcuto implicitamente (in base alla progettazione). Di solito si trova tranquillamente in uno sfondo in attesa che alcuni si verifichino e solo allora fa un vero lavoro (connessione in entrata ecc.). In realtà, il demone può essere sia rinnegato (più probabilmente) sia processo in background a seconda del suo design.

Spero che questa spiegazione possa aiutare a distinguere questi tipi di processi.


Bello. La tabella dei processi appartiene al genitore? Quindi gli zombi muoiono senza il loro padrone?
Anatoly Techtonik,

Tabella non è una parola giusta. È piuttosto un processo tree. Sì, certo, il genitore non è obbligato a terminare dopo che è terminato figlio (ma può farlo se era in attesa che un figlio finisse l'elaborazione di una sorta di roba). Ma se il genitore terminasse, il bambino terminerebbe definitivamente. È possibile eseguire topdal proprio terminale e quindi premere shift-vper visualizzare gli alberi di processo in modo selvaggio.
ddnomad,

1
Il licenziamento di un genitore non uccide i suoi figli. I bambini orfani hanno l'ID del processo genitore modificato in init (1).
psusi

@psusi hai ragione, ho dimenticato che è così solo con i processi avviati nel terminale. Correggerò la mia risposta.
ddnomad,

Rimuoverei semplicemente la frase "sparirebbe presto da una tabella". Suggerisce che in qualche modo svanisce automaticamente dopo qualche tempo, ma non è così; la "scomparsa" è un evento molto concreto.
AnoE
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.