Documentation: Architecture de la session Linux

20

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.

Stefan
la source
4
On ne peut pas répondre à cette question car chaque distribution fait son propre truc. Pire encore, les environnements de bureau KDE et GNOME diffèrent considérablement en ce qui concerne ce qui se passe après le démarrage du système de fenêtrage X. Pire encore, les distributions changent leur façon de faire - vous mentionnez systemd qui est relativement nouveau. Maintenant, si vous voulez une réponse indépendante de la distribution, c'est "le noyau Linux démarre init, et tout le reste dépend de la façon dont init est configuré". Cette réponse est aussi superficielle que large, tandis que pour chaque réponse profonde, vous devrez affiner votre question au moins aux versions de distribution.
Thorsten Staerk
1
veuillez diviser votre question. Par exemple, je pourrais vous dire de chercher gnome-session et startkde comme le processus "root session" qui aurait besoin de plus d'explications.
Thorsten Staerk
1
@ thorsten-staerk: "on ne peut pas répondre parce que chaque distribution fait ses propres trucs" Donc vous dites que je ne peux faire aucune hypothèse sur les démons qui fonctionnent? Je ne peux pas vraiment croire ça. Désolé, mais diviser la question ne donnera pas la réponse que je recherche. Mais je vais essayer de reformuler «Desktop-agnostic»: je recherche le plus petit dénominateur commun, ou l'ensemble minimum de démons en cours d'exécution (et la justification de chacun d'eux), attendus dans une session. Comment ils interagissent et comment cet ensemble change avec différents types de sessions (y a-t-il un dbusd dans une session de terminal? Via SSH?)
Stefan
1
Linux fonctionne sur des appareils qui n'ont rien d'autre qu'un écran LCD. Il fonctionne également sur les téléphones mobiles qui n'ont pas d'AppStore ni d'appareil photo. Il fonctionne également sur un Samsung Galaxy et sur des ordinateurs centraux. Il peut - c'est logique - utiliser plusieurs téraoctets de RAM et il peut tenir dans quelques kilo-octets. Je crains que le plus petit dénominateur commun d'une session Linux soit Linux et que vous ayez la "liberté de choix" qui est parfois moche pour choisir ce dont vous avez besoin. Pour un ordinateur de bureau, j'essaierai d'énumérer les plus petits dénominateurs communs, mais vous ferez mieux de poser des questions sur dbus au lieu de "tout".
Thorsten Staerk

Réponses:

8

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.

Thorsten Staerk
la source
1
Il s'agit d'un bon aperçu générique des étapes de démarrage d'un système Linux. Le logiciel spécifique (par exemple grub, lilo, u-boot) change mais la fonction est la même. Je soupçonne que vous êtes le plus intéressé par le processus d'initialisation, alors concentrez-vous sur les étapes 8 et 9. sysvinit (/ etc / inittab) est à peu près obsolète en faveur de systemd OU upstart. Les deux peuvent exécuter / surveiller les services sysvinit.
dturvene
Pas d'appels via le d-bus pour mettre sa fenêtre au point. -
Robert Siemer
0

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.

Communauté
la source
Tout savoir sur la façon d'utiliser un fouet électrique ne me dit rien sur la façon dont le gâteau est fait. "Lire tous les doc des packages qui vous intéressent" - c'est une réponse plutôt inutile. La documentation que vous mentionnez m'a dit ce que ces choses font. Mais je veux savoir à quoi ils servent. «Pose juste de bonnes questions» - ma question est simple et directe: où est la documentation?
Stefan
1
Vous devrez peut-être apprendre à demander pour obtenir la réponse que vous attendez. Dans ce cas, je voudrais vous indiquer une FAQ très utile Comment poser des questions The Smart Way
0

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.

tjb63
la source