Cosa sono i "leader della sessione" in `ps`?

Cosa sono i leader della sessione, come in ps -dcui seleziona tutti i processi tranne i leader della sessione?

process ps session

— sono io
fonte

Risposte:

In Linux, a ogni processo sono associati diversi ID, tra cui:

ID processo (PID)

Numero arbitrario che identifica il processo. Ogni processo ha un ID univoco, ma dopo che il processo termina e il processo padre ha recuperato lo stato di uscita, l'ID processo viene liberato per essere riutilizzato da un nuovo processo.
Parent Process ID (PPID)

Questo è solo il PID del processo che ha avviato il processo in questione.
Process Group ID (PGID)

Questo è solo il PID del leader del gruppo di processi. Se PID == PGID, questo processo è un leader del gruppo di processi.
ID sessione (SID)

Questo è solo il PID del leader della sessione. Se PID == SID, questo processo è un leader della sessione.

Le sessioni e i gruppi di processi sono solo modi per trattare una serie di processi correlati come un'unità. Tutti i membri di un gruppo di processi appartengono sempre alla stessa sessione, ma una sessione può avere più gruppi di processi.

Normalmente, una shell sarà un leader della sessione e ogni pipeline eseguita da quella shell sarà un gruppo di processi. Questo per rendere più facile uccidere i bambini di una shell quando esce. (Vedi uscita (3) per i dettagli cruenti.)

Non credo che esista un termine speciale per un membro di una sessione o di un gruppo di processi che non sia il leader.

— CJM
fonte

Nota: utilizzare ps xao pid,ppid,pgid,sid,commper visualizzare questi ID.

— Mike R,

Perché le persone non danno più di tali risposte illustrative basate sul confronto nel mondo reale. +1

— RootPhoenix

Un leader di sessione è un processo in cui ID sessione == ID processo. Sembra forzato, ma l'id di sessione è ereditato da processi figlio. Alcune operazioni all'interno di UNIX / Linux operano su sessioni di processo, ad esempio negando l'id di processo durante l'invio alla chiamata o al comando del sistema kill. L'uso più comune per questo è quando ci si disconnette da una shell. Il sistema operativo invierà kill -HUP -$$, che invierà un segnale SIGHUP (hangup) a tutti i processi con lo stesso ID di sessione della shell. Quando rinneghi un processo, l'ID di sessione del processo viene modificato dalla shell, quindi non risponderà al segnale di riaggancio. Questa è una parte del processo per diventare un processo daemon.

La maggior parte dei processi richiamati dal gestore di finestre / dall'ambiente grafico hanno lo stesso ID di sessione di uno dei programmi di avvio. Ciò consente al sistema operativo di eseguire la stessa kill -HUP -$$operazione su tutti i programmi: come browser, lettore musicale, libreoffice, client di messaggistica istantanea, ecc. Questi sono i processi che non sono leader della sessione.

— Arcege
fonte

Per favore, non preoccuparti, ma potrei aver bisogno di un po 'più di chiarimenti: - il leader della sessione è uno, come si chiamano gli altri e come sono (comportamento, cosa fanno di diverso dal leader della sessione)?

— its_me

Sono chiamati membri della sessione, credo.

— Arcege,

Mi piace la tua spiegazione, ma mi manca ancora un punto: IIUC, in qualsiasi momento ogni processo che ho avviato è in realtà figlio della shell con cui ho effettuato l'accesso (a meno che non lo abbia rinnegato, ovviamente). Perché il sistema operativo non dovrebbe semplicemente percorrere l'albero dei processi e uccidere tutti i fratelli di questo processo e i loro fratelli? (In realtà è quello che ho sempre pensato che facesse ... fino ad oggi: D) Allora, qual è la logica dietro l'utilizzo delle sessioni?

— Alois Mahdal,

È necessario determinare a fondo quando un processo non fa più parte della sessione originale (shell di login o demone, ad esempio). Un pensiero potrebbe essere quello di cambiare automaticamente il PPID (parent pid) in 1, ma ciò spezza l'albero del processo. Un nuovo ID sessione crea un gruppo a cui è possibile inviare un segnale insieme. Un esempio di ciò è la GUI, spegni firefox come sessione separata. Quindi, quando si preme il pulsante [X], inviare un segnale alla sessione di firefox e ai suoi figli, ma il gestore delle finestre non è interessato - non è possibile farlo con relazioni PPID-PID diritte.

— Arcege,

Quando la GUI muore, l'intero albero del processo, non il gruppo di sessioni, potrebbe ricevere il segnale. Due diversi comportamenti desiderati: uccidere una 'app' (uccidere firefox e i suoi plugin), contro uccidere tutti i processi figlio (uscire da una GUI). Funzionamenti simili con emacs e chrome, mi aspetto.

— Arcege,

Pensavo di conoscere la risposta a questo, ma ho scritto un programma C per capirlo.

#include <stdio.h>
#include <unistd.h>

int
main(int ac, char **av)
{
        pid_t sid, mypid, pgid, gid;

        mypid = getpid();
        sid = getsid(0);
        pgid = getpgid(0);
        gid = getpgrp();

        printf("PID %d\n", mypid);
        printf("process group ID of session leader: %d\n", sid);
        printf("process group ID: %d\n", pgid);
        printf("process group ID: %d\n", gid);

        if (!fork())
        {
                mypid = getpid();
                sid = getsid(0);
                pgid = getpgid(0);
                gid = getpgrp();

                printf("child PID %d\n", mypid);
                printf("process group ID of session leader: %d\n", sid);
                printf("process group ID: %d\n", pgid);
                printf("process group ID: %d\n", gid);

                _exit(0);
        }

        return 0;
}

L'ho compilato con l' cc -g -o sid sid.c ho eseguito in diversi modi, per vedere cosa succede:

./sid
nohup ./sid > sid.out
setsid ./sid

Sono stato un po 'sorpreso da ciò che Linux (2.6.39) ha restituito. Ho anche trovato la pagina man della sezione 7, "credenziali".

Il mio consiglio è di fare man 7 credentials(o l'equivalente se non su Linux) e leggere la sezione relativa al gruppo di processo e alla sessione per vedere se riesci a risolverlo.

— Bruce Ediger
fonte

Essendo un principiante di Linux, non sono riuscito a capire cosa hai detto. Sembra che anche tu sia perplesso? Ma probabilmente sei abbastanza ben informato da capire cosa significasse la risposta di Arcege. Se lo fai, puoi per favore spiegare lo stesso in modo più chiaro?

— its_me

Interessante ... grazie ... Quindi, l'ID sessione (SID) è il PID del terminale per ./side nohup ./sid, e quando si esegue setsid ./sid, l'ID sessione (SID) è nuovo ed è uguale al PID del processo ... I ' Non sono sicuro del perché Nohup abbia impedito la forcella (o sembra), ma penso di avere l'idea generale ...

— Peter.O