Moi ce que je comprend du document de Lennart, c'est que systemd utilise dbus pour mieux controller les processus, en gros, il utilise un service dbus pour savoir quel process il a forké…
Mais cette fonctionnalité n'est valable que pour les process démarré après dbus…
POur les autres, il utilise, attention au magie, un fichier service.pid dans /run comme le faisait sysvinit dans /var/run.
Mais je ne pense pas dans l'exemple de abrt que ce soit systemd qui crée com.redhat.abrt, il s'en sert c'est tout.
Donc en gros, il utilise dbus pour controller des process linké à libdbus, donc si dbus est planté avec sysvinit on avait un démon lancé alors que ce dont il a besoin ne fonctionne pas, avec systemd un process non lancé parce que ce dont il a besoin n'a pas réussi à se lancer.
J'aimerai donc savoir ou est le problème, car je ne le comprend pas.
[^] # Re: Questions
Posté par gnumdk (site web personnel) . En réponse au journal Linux from scratch face à udev. Évalué à 7.
Moi ce que je comprend du document de Lennart, c'est que systemd utilise dbus pour mieux controller les processus, en gros, il utilise un service dbus pour savoir quel process il a forké…
Mais cette fonctionnalité n'est valable que pour les process démarré après dbus…
POur les autres, il utilise, attention au magie, un fichier service.pid dans /run comme le faisait sysvinit dans /var/run.
Mais je ne pense pas dans l'exemple de abrt que ce soit systemd qui crée com.redhat.abrt, il s'en sert c'est tout.
Donc en gros, il utilise dbus pour controller des process linké à libdbus, donc si dbus est planté avec sysvinit on avait un démon lancé alors que ce dont il a besoin ne fonctionne pas, avec systemd un process non lancé parce que ce dont il a besoin n'a pas réussi à se lancer.
J'aimerai donc savoir ou est le problème, car je ne le comprend pas.