Ecco una definizione comune di processo in background:
“Un processo in background è un programma in esecuzione senza linput dellutente. A numero di processi in background possono essere eseguiti su un sistema operativo multitasking, come Linux, mentre lutente sta interagendo con il processo in primo piano Alcuni processi in background, come i daemon, ad esempio, non richiedono mai linput dellutente. Altri sono solo temporaneamente in background mentre lutente è impegnato con il programma attualmente in esecuzione in primo piano. In modo che un altro processo possa dormire e occupare spazio di swap, finché non viene attivato, il che lo rende attualmente un processo in background. “
Data questa definizione, Questo non farebbe un processo come apache2 un processo in background poiché non interagisce mai con linput dellutente nel terminale? E non lo prenderebbe in considerazione la maggior parte dei processi in background del processo, dal momento che la maggior parte dei processi in esecuzione su un sistema non gestisce linput dellutente nel terminale? Stranamente, personalmente non considererei apache2 un processo in background poiché un utente interagisce con esso tramite richieste http (ma non un terminale).
Commenti
- Penso che ci siano due definizioni qui. Una riguarda linput dellutente (se un processo può accettare linput dellutente, come il terminale). Laltra è se un processo sta dormendo e si trova nello spazio di swap oppure no. Qui puoi fare riferimento a entrambi come processi in background, il che rende il termine confuso
Answer
Un processo in primo piano non lo fa richiede linterazione dellutente. Puoi eseguire
cp very_large_file destination e questo bloccherebbe il tuo terminale fino al termine della copia e verrebbe considerato un processo in primo piano senza interazione da parte dellutente. qui è se il processo blocca lesecuzione di altri processi finché non termina.
Puoi fare un processo in primo piano in uno sfondo:
1- Aggiunta di una e commerciale ( & ) alla fine della riga di comando:
cp very_large_file destination & 2- Arrestare un processo in primo piano e portarlo in secondo piano:
cp very_large_file destination CTRL + Z
bg Ora apache2 conterà sicuramente come un processo in background: sì, puoi interagire con esso tramite richieste http ma ascolta semplicemente sulla porta 80 (per impostazione predefinita) in attesa di tale richiesta: non blocca il sistema finché lutente non fa una richiesta.
E perché ritieni che la maggior parte dei processi vengano considerati processi in background? Questo è effettivamente normale in un “sistema operativo multi-tasking”.
Commenti
- Per curiosità, se ho un programma che blocca ma è in esecuzione in una sessione dello schermo GNU o tmux, quindi lascio quella sessione screen / tmux e restituisco il controllo al terminale (ma ovviamente ignorano il segnale HUP (hangup) quindi sono ancora in esecuzione), sarebbero considerati uno sfondo processi? Immagino che sosteresti che sono processi in primo piano poiché allinterno della loro sessione stanno bloccando, anche se non stanno bloccando nel terminale principale.
- @JohnMerlino direi che
screen/tmuxè il processo in primo piano in questo caso e quando " restituisci il controllo a un terminale " lo mandi in background.
Risposta
Esistono due definizioni comuni di “Processo in background”, uno in termini generali e uno preciso e specifico per unix.
In senso lato, puoi chiamare “processo in background” qualsiasi processo che non sta interagendo con lutente seduto al console. In questo senso, Apache è un processo in background.
Nella terminologia unix, “processo in background” ha una definizione precisa. Un processo in background è un processo che viene avviato da un terminale ma attualmente non può interagire con il ter minal. (Sto semplificando non considerando i gruppi di processi.) In genere si ottiene un processo in background avviando un processo in background in una shell:
$ myprogram & [1] 12345 $ o avviando un programma, quindi sospendendolo e lasciando che continui in background:
$ myprogram ^Z [1]+ Stopped myprogram $ bg [1]+ myprogram & $ Se avvii un programma senza & , è in primo piano. Può esserci un solo processo in primo piano in un dato terminale alla volta. (O più in generale, un singolo gruppo di processi, se il processo in primo piano avvia alcuni sottoprocessi.) La shell incorporata bg e fg cambia quale processo è in primo piano. Quando un processo è in background, se tenta di leggere o scrivere sul terminale, viene interrotto da un segnale SIGTTIN o SIGTTOUT .
Trovo che la tua intuizione che Apache non sia un processo in background perché interagisce con lutente su HTTP è strana. Apache non sta interagendo con lutente: sta interagendo con un browser web remoto (che sta interagendo con lutente) o un client automatizzato (che non sta interagendo con lutente). Se consideri qualsiasi processo che interagisce con un interattivo come un processo interattivo, allora qualsiasi processo è interattivo, il che lo rende un concetto inutile.
La definizione che citi fonde processi in background con processi inattivi. Non cè motivo per cui un processo in background venga sospeso o sostituito più di un processo in primo piano. Ad esempio, un processo in background potrebbe eseguire calcoli pesanti. Al contrario, se lutente si allontana dalla console e sono presenti altri processi attivi, i processi in primo piano potrebbero essere sostituiti.