Documentation: Architecture de la session Linux

Je recherche une bonne documentation générale décrivant la pile de démons et de services impliqués dans une session Linux moderne. Bien qu'ayant lu diverses documentations sur dbus, et systemd, je n'ai toujours pas une vue d'ensemble.

En particulier, je cherche des réponses à ces questions (ne répondez pas aux questions, elles devraient seulement clarifier le type de documentation que je recherche):

• Après la connexion, quel processus est la racine de la session de l'utilisateur?

• Quels processus devraient être lancés et pourquoi? Je recherche une réponse indépendante du bureau, que Gnome, KDE, FVWM ou un simple shell soit démarré.

• Quel rôle jouent tous ces démons? Lequel d'entre eux fonctionnerait seul, qui dépend des autres? Laquelle devrait être lancée par qui, pourquoi et pour combien de temps? Et qui devrait entretenir ce zoo?

Je demande, parce que je trouve que j'ai un zoo tout juste après daemons course démarrage: systemd-journald, systemd-udevd, dbus-daemon, systemd-logind. Mais pas assez: En dehors de ceux - ci, en cours PDF viewer ultra-léger zathura encore remplit ma session avec dbus-launch, dbus-daemon, at-spi2-registrydet at-spi-bus-launcher, ce dernier lancement encore une autre dbus-daemon. Aucun d'eux n'a été là auparavant, aucun n'a été invité, mais ils resteront dans la maison, me donnant un sentiment effrayant, jusqu'à ce que je me déconnecte. Je suis sûr que je manque quelque chose ici ...

Un autre exemple: après la connexion, j'ai un systemdUID avec mes utilisateurs, mais je n'ai aucune idée de ce qu'il doit faire (depuis la version 206, je pense que je ne suis pas censé l' utiliser comme gestionnaire de session, non?). Il a un processus enfant (sd-pam), sur lequel je n'ai pas trouvé de documentation.

Que font-ils? Quelle est l'idée derrière cette configuration?

Pour clarifier mon point de vue: dans «l'ancien temps», il suffisait de savoir que loginlancerait mon shell de connexion ( bash, en cours d'exécution ~/.profile), et à partir de là, je pouvais continuer à créer une session, selon les circonstances, peut-être le lancement screen, ou startx.

Je suis tellement fasciné par votre question que j'y ai répondu sur linuxintro . Voici la réponse adaptée à votre question:

Lorsqu'un PC typique avec Linux comme Fedora, SUSE ou Ubuntu démarre, les étapes seront les suivantes:

1. Le BIOS exécute l'auto-vérification
2. Le BIOS charge le secteur de démarrage et l'exécute
3. Le chargeur de démarrage comme grub ou lilo est exécuté
4. Le menu de démarrage est affiché (facultatif)
5. Le noyau est chargé
6. Le disque RAM initial est chargé
7. Le noyau est exécuté
8. Le noyau exécute init

9. init s'exécute, en fonction de votre distribution, version et configuration

   • Scripts d'initialisation SysV ou
   • systemd ou
   • parvenu

Le sens de tous ces programmes est de lancer des services comme

• dbus qui permet la communication entre les applications afin qu'une application puisse appeler des fonctions d'une autre application en cours d'exécution. C'est quelque chose qui n'est généralement pas visible pour les utilisateurs, par exemple une application appelant le gestionnaire de fenêtres pour mettre sa propre fenêtre en évidence
• connexion qui permet aux utilisateurs de se connecter sur les terminaux CTRL_ALT_F *. Le processus de connexion vu par ps -A sera en cas de systemd être systemd-logind (peut encore varier selon la distribution)
• udev qui a beaucoup de noms, par exemple pour moi je le trouve avec ps -A comme systemd-udevd. Il affecte par exemple le périphérique gère dans / dev / aux périphériques que vous connectez, par exemple un disque USB
• cron qui exécutera des commandes basées sur un calendrier dans / etc / crontab, et dispose également d'une fonction "@reboot" pour démarrer les commandes au démarrage.

10) le processus de connexion, géré par systemd attendra une connexion sur un terminal virtuel, on est généralement accessible en appuyant sur CTRL_ALT_F1

11) Typiquement et par défaut, le processus d'initialisation va maintenant démarrer le gestionnaire d'affichage, par exemple kdm (gestionnaire d'affichage KDE) ou xdm

12) le gestionnaire d'affichage va maintenant démarrer le système graphique. Il n'y a pratiquement pas de système graphique mais Xorg (hildon est pour les appareils embarqués).

13) Le gestionnaire d'affichage conseillera au serveur Xorg d'afficher un écran de connexion

Le démarrage est maintenant terminé et l'ordinateur attend que l'utilisateur se connecte.

14) sur le journal de l'utilisateur dans le gestionnaire d'affichage démarrera un environnement de bureau comme KDE, GNOME ou XFCE4. Le processus racine pour une session KDE d'un utilisateur sera appelé startkde, le processus racine pour GNOME sera appelé gnome-session, le processus racine pour XFCE4 sera appelé xfce4-session

15) KDE démarre généralement tous les fichiers exécutables à partir de ~ / .kde / Autostart et les fichiers .desktop à partir de / etc / xdg / autostart (voir les tâches de planification ).

16) Lorsque l'utilisateur s'est connecté graphiquement et clique sur une icône pour ouvrir une console, bash est généralement exécuté. Bash exécutera d'abord .bashrc puis

17) Lorsque l'utilisateur ouvre un shell de connexion, cela signifie qu'il doit se connecter via un mot de passe ou une clé autorisée. Il peut le faire sur la console CTRL_ALT_F1 ou en se connectant à un ordinateur, par exemple localhost. Ensuite, les scripts .sh de /etc/profile.d et .bashrc seront exécutés.

La réponse est 42. Thorsten Staerk a déjà expliqué le principal problème dans les commentaires.

Pour vous aider à avoir une vue d'ensemble, vous devez savoir que les logiciels Linux et Open Source sont écrits et maintenus par des millions de bénévoles et d'entreprises. Il n'est donc pas facile de suivre la croissance.

D'un autre côté, il y a beaucoup de documentation: les pages de manuel de chaque logiciel, une bonne explication de ce qu'est D-Bus , les listes de diffusion des développeurs, Google , etc. Prenez donc quelques années et lisez tous les documents des packages qui vous intéressent. Si vous en avez besoin plus rapidement, posez simplement de bonnes questions sur Unix et Linux .

Bonne chance.

Avant de donner ma version de la réponse, permettez-moi de commencer par quelques définitions

Linux == 'Un noyau de système d'exploitation "Linux System ==" Une sorte de système construit autour du noyau Linux "Session sur un système Linux ==" Un ensemble de programmes utilisateur associés fonctionnant sur un système Linux "

Plus vous vous éloignez du noyau, moins deux "systèmes" ont de chances d'avoir quelque chose en commun. Ce qui signifie qu'il n'y a pas vraiment de définition sensée d'une "session Linux moderne"

Franchement, l'attente qu'il devrait y avoir une sorte de documentation système globale qui vous donne tous les composants est une attente qui ne sera pas satisfaite dans la plupart des régions du monde open source. Les développeurs Open Source écrivent des programmes pour résoudre (ou re-résoudre!) Les problèmes spécifiques dont ils se soucient - ils vont donc simplement documenter cette partie - si cela! :-)

Vous aurez peut-être plus de chance avec les manuels disponibles avec les distributions Linux commerciales, mais étant donné la nature conservatrice de la plupart d'entre eux, vous pouvez affirmer que leurs versions ne sont pas "modernes"!

La clé conseil que je donnerais est que un un sens très général des systèmes Unix / Linux sont heirachical. J'avais l'habitude de dire aux gens que j'aimais les systèmes nix parce que je pouvais commencer par init, et à partir de là, comprendre tout ce qui se passait sur un système. Systemd et ses amis ont un peu changé cela, mais le principe de base est le même - commencez par le haut et descendez - les "programmes constituant une session" sont généralement ceux qui ont commencé à partir du moment où vous entrez dans l'héritachie. Donc, si vous utilisez ssh, vous obtiendrez probablement le shell par défaut, car c'est ainsi que ssh fonctionne. Si vous vous connectez via une interface graphique, vous obtiendrez tout ce qui est démarré par votre gestionnaire de connexion, car c'est ainsi que votre gestionnaire de connexion fonctionne

Beaucoup de frameworks de bureau rendent cela un peu plus difficile, en exécutant divers démons de service au niveau utilisateur ou système - et parfois, ils seront démarrés à la demande par quand le premier programme qui en a besoin démarre - regardez les options de ligne de commande du programmes que vous exécutez, il existe très probablement des options pour arrêter ce comportement et exécuter l'application en mode "nu".

Malheureusement, cela signifie que "lire la documentation des programmes individuels" est le seul moyen de tout comprendre, et qu'il n'y a pas un "ensemble minimum de démons" pour une session - il y a juste la façon dont une distribution donnée fonctionne pour un donné connexion / méthode d'accès, et c'est la distribution, le bureau et la méthode de connexion spécifiques.