Documentazione: Architecture of Linux Session

Sto cercando una buona documentazione generale che descriva la pila di demoni e servizi coinvolti in una moderna sessione Linux. Pur avendo letto vari documenti dbuse systemd, non riesco ancora ad avere una visione d'insieme.

In particolare, sto cercando le risposte a queste domande (non rispondere alle domande, dovrebbero solo chiarire che tipo di documentazione sto cercando):

• Dopo aver effettuato l'accesso, quale processo è la radice della sessione dell'utente?

• Quali processi dovrebbero essere avviati e perché? Sto cercando una risposta indipendente dal desktop, indipendentemente dal fatto che Gnome, KDE, FVWM o una semplice shell venga avviata.

• Che ruolo svolgono tutti questi demoni? Chi di loro correrebbe da solo, che dipenderà dagli altri? Quale dovrebbe essere iniziato da chi, perché e per quanto tempo? E chi dovrebbe mantenere quello zoo?

Mi sto chiedendo, perché ho scoperto che ho un intero zoo di demoni che corre a destra dopo l'avvio: systemd-journald, systemd-udevd, dbus-daemon, systemd-logind. Ma non basta: Oltre a questi, Esecuzione ultra-leggero PDF-viewer zathura ulteriormente popola la mia sessione con dbus-launch, dbus-daemon, at-spi2-registryd, e at-spi-bus-launcher, il secondo lancio ancora un altro dbus-daemon. Nessuno di loro è mai stato lì prima, nessuno è stato invitato, ma rimarranno in casa, dandomi una sensazione inquietante, fino a quando non mi disconnetto. Sono sicuro che mi manca qualcosa qui ...

Un altro esempio: dopo il login, ho un systemdUID in esecuzione con i miei utenti, ma non ho idea di cosa dovrebbe fare (dalla versione 206 penso che non dovrei usarlo come session manager, giusto?). Ha un processo figlio (sd-pam), di cui non sono riuscito a trovare la documentazione.

Cosa fanno? Qual è l'idea alla base di questa configurazione?

Per chiarire la mia prospettiva: nei "vecchi tempi" era sufficiente sapere che loginavrebbe lanciato la mia shell di login ( bash, in esecuzione ~/.profile), e da quel momento avrei potuto continuare a costruire una sessione, a seconda delle circostanze, magari del lancio screen, o startx.

Sono così affascinato dalla tua domanda che ho risposto su linuxintro . Ecco la risposta su misura per la tua domanda:

Quando un tipico PC con Linux come Fedora, SUSE o Ubuntu si avvia, i passaggi saranno i seguenti:

1. Il BIOS esegue l'autotest
2. Il BIOS carica il settore di avvio e lo esegue
3. Bootloader come grub o lilo viene eseguito
4. Viene visualizzato Bootmenu (opzionale)
5. Il kernel è caricato
6. Disco RAM iniziale caricato
7. Il kernel viene eseguito
8. Il kernel esegue init

9. init viene eseguito, a seconda della distribuzione, della versione e della configurazione

   • Script di inizializzazione SysV o
   • systemd o
   • parvenu

Il senso di tutti questi programmi è quello di avviare servizi come

• dbus che consente la comunicazione tra le applicazioni in modo che un'applicazione possa chiamare funzioni da un'altra applicazione in esecuzione. Questo è qualcosa che di solito non è visibile agli utenti, ad esempio un'applicazione che chiama il gestore delle finestre per mettere a fuoco la propria finestra
• login che consente agli utenti di accedere ai terminali CTRL_ALT_F *. Il processo di accesso visto da ps -A in caso di systemd sarà systemd-logind (può variare di nuovo in base alla distribuzione)
• udev che ha molti nomi, ad esempio per me lo trovo con ps -A come systemd-udevd. Assegna ad esempio il dispositivo gestisce in / dev / ai dispositivi collegati, ad esempio un disco USB
• cron che eseguirà i comandi in base a una tabella oraria in / etc / crontab e ha anche una funzione "@reboot" per avviare i comandi all'avvio.

10) il processo di login, gestito da systemd attenderà un login su un terminale virtuale, in genere è raggiungibile premendo CTRL_ALT_F1

11) in genere e per impostazione predefinita, il processo di inizializzazione ora avvia il display manager, ad esempio kdm (display manager di KDE) o xdm

12) il display manager ora avvierà il sistema grafico. Praticamente non esiste un sistema grafico tranne Xorg (hildon è per dispositivi embedded).

13) il display manager consiglierà al server Xorg di visualizzare una schermata di accesso

Ora l'avvio è completo e il computer attende che l'utente acceda.

14) al log utente nel display manager verrà avviato un ambiente desktop come KDE, GNOME o XFCE4. Il processo di root per la sessione KDE di un utente si chiamerà startkde, il processo di root per GNOME si chiamerà gnome-session, il processo di root per XFCE4 si chiamerà xfce4-session

15) KDE di solito avvia tutti i file eseguibili da ~ / .kde / Autostart e i file .desktop da / etc / xdg / autostart (vedi le attività di pianificazione ).

16) Quando l'utente ha effettuato l'accesso graficamente e fa clic su un'icona per aprire una console, in genere bash verrà eseguito. Bash eseguirà prima .bashrc quindi

17) Quando l'utente apre una shell di accesso significa che deve accedere tramite password o chiave autorizzata. Può farlo sulla console CTRL_ALT_F1 o inviando un messaggio al computer, ad esempio localhost. Quindi verranno eseguiti gli script .sh da /etc/profile.d e .bashrc.

La risposta è 42. Thorsten Staerk ha già spiegato il problema principale nei commenti.

Per aiutarti ad avere una visione d'insieme, devi sapere che il software Linux e Open Source è scritto e gestito da milioni di volontari e aziende. Quindi, non è facile tenere il passo con la crescita.

D'altra parte, c'è molta documentazione: le pagine man di ogni pezzo di software, una buona spiegazione di cosa sia D-Bus , le mailing list degli sviluppatori, Google e così via. Quindi prenditi qualche anno di tempo e leggi tutti i documenti sui pacchetti che ti interessano. Se ne hai bisogno più velocemente, fai solo alcune buone domande su Unix e Linux .

In bocca al lupo.

Prima di dare la mia versione della risposta, vorrei iniziare con un paio di definizioni

Linux == 'Un kernel del sistema operativo "Sistema Linux ==" Qualche tipo di sistema costruito attorno al kernel Linux "Sessione su un sistema Linux ==" Alcuni set di programmi utente correlati in esecuzione su un sistema Linux "

Più ti allontani dal kernel, meno è probabile che due "sistemi" abbiano effettivamente qualcosa in comune. Ciò significa che non esiste davvero alcuna definizione ragionevole di "Sessione Linux moderna"

Francamente, l'aspettativa che ci dovrebbe essere una sorta di documentazione generale del sistema che fornisca tutti i componenti è un'aspettativa che non sarà soddisfatta nella maggior parte del mondo open source. Gli sviluppatori Open Source stanno scrivendo programmi per risolvere (o ri-risolvere!) I problemi specifici a cui tengono - quindi documenteranno solo quella parte - in questo caso! :-)

Potresti avere più fortuna con i manuali disponibili con le distribuzioni commerciali di Linux, tuttavia, data la natura conservativa della maggior parte di quelli, puoi sostenere che le loro versioni non sono "moderne"!

Il consiglio chiave che darei è che in un senso molto generale i sistemi unix / linux sono ereditari. Dicevo alle persone che mi piacevano i sistemi nix perché potevo iniziare con init e da lì capire tutto quello che stava succedendo su un sistema. Systemd e amici lo hanno cambiato un po ', ma il principio di base è lo stesso - inizia dall'alto e lavora in basso - i "programmi che compongono una sessione" sono generalmente quelli che sono iniziati dal punto in cui entri nell'erede. Quindi, se accedete a ssh, probabilmente otterrete qualunque sia la vostra shell predefinita, poiché è così che funziona ssh. Se accedi tramite un'interfaccia grafica, otterrai tutto ciò che viene avviato dal tuo gestore degli accessi, in questo modo funziona il tuo gestore degli accessi

Molti framework desktop rendono questo un po 'più difficile, eseguendo vari demoni di servizio a livello di utente o di sistema - e a volte, questi saranno avviati su richiesta da un quando inizia il primo programma che li necessita - guarda le opzioni della riga di comando del programmi che stai eseguendo, ci sono opzioni molto probabili per fermare questo comportamento ed eseguire l'applicazione in modalità "nuda".

Sfortunatamente, questo significa che "leggere la documentazione dei singoli programmi" è l'unico modo per capirlo tutto e che non esiste un "set minimo di demoni" per una sessione - c'è solo il modo in cui una determinata distribuzione funziona per un dato metodo di accesso / accesso, ovvero distribuzione, desktop e metodo di accesso specifici.