ouhaip.
Mais ça ne change fondamentalement l'admin des services, en fait. Remplace Sxx par before et after Ajoute les notions de dépendances et de conflits et tu obtiens la gestion du service. Ensuite, si ton service a des besoins particuliers en terme d'option : par exemple fourni par le logiciel dont s'occupe le service, alors tu enrichi la directive ExecStart=. S'il s'agit d'options en dehors dudit logiciel, par exemple, tu pourra utiliser la directe ExecStartPre=.
D'un point de vue admin l'avantage est d'avoir des déclaratifs dont la structure est très claire, en exagérant on peut dire similaire à un fichier de conf typique de freedesktop.
C'est donc plus simple de créer un service, mais cela enlève le plaisir du script aux petits onions ce qui est sommes toutes assez subjectif. Par contre l'inconvénient (que j'y vois, pour le moment) est l'éclatement de la structure du gestionnaire de services, ça c'est délicat à prendre en main, faut se faire la main dessus quelques temps, nous ne sommes plus du tout dans un /etc/init.d/ bien propret sur lui (et /etc/systemd/ peut ne pas suffire) Peut être qu'à l'avenir systemd gagnera en compactage (en cohérence ?), pour le moment c'est parfois difficile de se retrouver dans les .target, les .services, et à divers endroit de la hiérarchie du FS... On peut se contenter de /etc/systemd/ mais pas toujours.
Systemd uses a different syntax from bash, so please resist the temptation to reuse the same configuration file for the traditional initscript and the service file. Resist even though some service files in the Gentoo systemd overlay do use the same configuration files as the corresponding traditional initscripts -- they are just buggy.
Et l'inconvénient, que tu soulignes (et qui, il me semble est bien réel) c'est que systemd lui même à un problème, tout va devenir très délicat, oui. M'enfin des logiciels rock-solid, systemd ne sera pas le premier ;)
[^] # Re: Question sur systemd
Posté par bubar🦥 . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 4.
ouhaip.
Mais ça ne change fondamentalement l'admin des services, en fait. Remplace Sxx par before et after Ajoute les notions de dépendances et de conflits et tu obtiens la gestion du service. Ensuite, si ton service a des besoins particuliers en terme d'option : par exemple fourni par le logiciel dont s'occupe le service, alors tu enrichi la directive ExecStart=. S'il s'agit d'options en dehors dudit logiciel, par exemple, tu pourra utiliser la directe ExecStartPre=.
D'un point de vue admin l'avantage est d'avoir des déclaratifs dont la structure est très claire, en exagérant on peut dire similaire à un fichier de conf typique de freedesktop.
C'est donc plus simple de créer un service, mais cela enlève le plaisir du script aux petits onions ce qui est sommes toutes assez subjectif. Par contre l'inconvénient (que j'y vois, pour le moment) est l'éclatement de la structure du gestionnaire de services, ça c'est délicat à prendre en main, faut se faire la main dessus quelques temps, nous ne sommes plus du tout dans un /etc/init.d/ bien propret sur lui (et /etc/systemd/ peut ne pas suffire) Peut être qu'à l'avenir systemd gagnera en compactage (en cohérence ?), pour le moment c'est parfois difficile de se retrouver dans les .target, les .services, et à divers endroit de la hiérarchie du FS... On peut se contenter de /etc/systemd/ mais pas toujours.
j're-sort ce lien :
http://patrakov.blogspot.com/2011/01/writing-systemd-service-files.html
qui résume assez bien l'état de l'art, il me semble.
Et l'inconvénient, que tu soulignes (et qui, il me semble est bien réel) c'est que systemd lui même à un problème, tout va devenir très délicat, oui. M'enfin des logiciels rock-solid, systemd ne sera pas le premier ;)