C'est pas tant systemd en tant que tel que le fait que logind gére la session ( cad s'assure que les accés sont revoqués quand il y en a plus besoin, etc ). Ensuite la question est pourquoi logind a besoin de systemd, et pourquoi personne n'a fait ça avant.
Logind a besoin d'un système qui va gérer les sessions de manière fiable ( cad sans fuite de process hors de la session ), et il se trouve que c'est l'un des points fort de systemd, cad via les cgroups. À son tour, la gestion des cgroups, pour être propre, requiert d'avoir un seul process qui gére ça ( histoire que l'état ne change pas sous nez et avec des races conditions ). A son tour, la gestion des process requiert d'avoir un PID1 qui est au courant du fait qu'il y a des cgroups pour les process. Soit il gére ça lui même ( ce que fait systemd ), soit il fait faire ça par un autre process ( ce que upstart aurait fait ).
Les devs de systemd est que pour éviter les races conditions et la fiabilité, c'est plus simple de faire ça dans un seul processus que dans 2 ( vu qu'il y a des délais, potentiellement des communications asynchrones, du code pour communiquer entre les 2 processus, et du code dans le premier pour relancer le 2eme, avec le code du 2eme pour relancer ce qu'il lance lui même, etc ). Donc c'est comme ça qu'on se retrouve avec logind qui a besoin de systemd, et systemd qui se retrouve avec le pid 1.
Je suis sur qu'on aurait pu le faire avant, mais si les premiers trucs au sujet de X sans root date de 2008 ( https://airlied.livejournal.com/59521.html ) et qu'il a fallu 6 ans pour faire les derniers pas, peut être que c'était pas si simple à faire de manière propre.
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 10.
La réponse est sur https://hansdegoede.livejournal.com/14268.html
C'est pas tant systemd en tant que tel que le fait que logind gére la session ( cad s'assure que les accés sont revoqués quand il y en a plus besoin, etc ). Ensuite la question est pourquoi logind a besoin de systemd, et pourquoi personne n'a fait ça avant.
Logind a besoin d'un système qui va gérer les sessions de manière fiable ( cad sans fuite de process hors de la session ), et il se trouve que c'est l'un des points fort de systemd, cad via les cgroups. À son tour, la gestion des cgroups, pour être propre, requiert d'avoir un seul process qui gére ça ( histoire que l'état ne change pas sous nez et avec des races conditions ). A son tour, la gestion des process requiert d'avoir un PID1 qui est au courant du fait qu'il y a des cgroups pour les process. Soit il gére ça lui même ( ce que fait systemd ), soit il fait faire ça par un autre process ( ce que upstart aurait fait ).
Les devs de systemd est que pour éviter les races conditions et la fiabilité, c'est plus simple de faire ça dans un seul processus que dans 2 ( vu qu'il y a des délais, potentiellement des communications asynchrones, du code pour communiquer entre les 2 processus, et du code dans le premier pour relancer le 2eme, avec le code du 2eme pour relancer ce qu'il lance lui même, etc ). Donc c'est comme ça qu'on se retrouve avec logind qui a besoin de systemd, et systemd qui se retrouve avec le pid 1.
Je suis sur qu'on aurait pu le faire avant, mais si les premiers trucs au sujet de X sans root date de 2008 ( https://airlied.livejournal.com/59521.html ) et qu'il a fallu 6 ans pour faire les derniers pas, peut être que c'était pas si simple à faire de manière propre.