On s’éloigne de ce dont on parle. Je vais te resituer le débat. Totof2000 à écrit :
En quoi systemd répond à ça ? Si un service fait semblant d'être démarré alors qu'il ne l'est pas, ce n'est pas la faute au système de démarrage, mais au service en lui même.
Socket activation
Socket activation occurs when a service allows systemd to listen for connections to a specific socket and, when systemd receives a connection on that socket, it starts the service. To do this, the upstream source needs to have some minor coding work to let systemd listen for connections on the socket and there needs to be a .socket file in %{_lib}/systemd/system/ that tells systemd to listen to that socket and what to start when a connection is received. This is similar in function to inetd and some, but not all, services coded to work with inetd will work with socket activation. Simila to inetd, using socket activation for on-demand loading will impose a startup time penalty so we currently do not use this feature in Fedora.
However, socket activation can also be used to allow parallel startup of services. If a service supports systemd socket activation as described above and we additionally start it explicitly on boot, then systemd will start it but allow things that depend on it to startup at the same time. If the dependent service makes a request to the socket activatable service before it has come up, then systemd will cause the request to wait until the socket activatable service has come up and can process the request. To achieve this effect, the service must be socket activatable as described above, the .service file for the service needs to have a Wants= line for the .socket, and the service must autostart. Since Fedora currently doesn't want any services to do on-demand loading, all socket activated services must autostart.
In practical terms this means if the upstream tarball ships with a socket file you need to contact FESCo to get permission to enable your service on boot. Once you have permission, you can package the .socket file and use the systemd scriptlets that enable the service by default. You need to also check the .service file to make sure it has a Wants= entry on the .socket file as that ensures that starting the service will also inform systemd of the socket.
Marotte a ajouté :
L'exemple du sleep est mal choisi. En attendant, sur une Squeeze je suis obligé de (re)démarrer snort et bacula (qui utilisent postgres) dans rc.local si je veux être sûr qu'ils soient bien démarrés au boot.
/Me a répondu (Je retire le cas 2 qui était en fait une boutade) :
Si le démon postgres rend la main au script avant d’être opérationnel, c’est un problème de postgres.
Marotte a sauté sur l’occasion pour pourrir les scripts du cas 2 mais sans répondre à la vrai interrogation (vois ci-dessus) :
/Me a précisé que le cas 2 était un fake, et demandé :
Ce que je voudrais, c’est que tu m’expliques comment dans le cas 1, (…), systemd est mieux que un script d’init. Comment systemd après avoir démarrer le démon, et que celui-ci rend la main, sait-il si oui ou non le service est fonctionnel ?
gnumdk me prend de haut, sans répondre à la question :
Je vais pas poster mon lien sur les "sockets activations" tous les 3 commentaires…
Je passe sur l’humour de Michel qui n’apporte rien au débat.
En attendant, je n’ai toujours pas compris comment systemd va permettre à Marotte de ne pas avoir à redémarrer bacula si postgress rend la main à systemd. Je ne vois pas comment systemd peut faire mieux qu’un script.
Quelqu’un aurait-il assez de patience pour m’expliquer ?
[^] # Re: Tu n'es pas le centre du monde
Posté par Anthony Jaguenaud . En réponse au journal Archlinux est morte.... Évalué à 1.
On s’éloigne de ce dont on parle. Je vais te resituer le débat.
Totof2000 à écrit :
gnumdk à répondu :
Signifiant (j’ai la flemme de traduire) :
Marotte a ajouté :
/Me a répondu (Je retire le cas 2 qui était en fait une boutade) :
Marotte a sauté sur l’occasion pour pourrir les scripts du cas 2 mais sans répondre à la vrai interrogation (vois ci-dessus) :
/Me a précisé que le cas 2 était un fake, et demandé :
gnumdk me prend de haut, sans répondre à la question :
Je passe sur l’humour de Michel qui n’apporte rien au débat.
En attendant, je n’ai toujours pas compris comment systemd va permettre à Marotte de ne pas avoir à redémarrer bacula si postgress rend la main à systemd. Je ne vois pas comment systemd peut faire mieux qu’un script.
Quelqu’un aurait-il assez de patience pour m’expliquer ?