Systemd et scripts /etc/init.d/.

--=-wNYhCZZkbznbR+JeL1tw
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Bonjour.

En fait, par défaut, en tout cas sous Debian, systemd va émuler l e
fonctionnement d'init, en ce qu'il utilisera les scripts init.d même
s'ils ne sont pas des unités systemd à proprement parler. Év idemment,
toutes les fonctionnalités de systemd ne fonctionneront pas sur les
scripts init.d, mais on peut au moins les lancer, les redémarrer et le s
arrêter.

Pour le reste, je ne sais pas.

Cordialement.

Le vendredi 06 novembre 2015 à 15:52 +0100, Migrec a écrit :

Bonjour,

Je me suis documenté sur le systemd mais j'ai encore quelques questi on
pratiques...

Sur mon serveur mis à jour depuis peu en version stable, le nouveau systemd a
remplacé l'ancien système. J'ai un soucis avec un script "perso " qui est dans
/etc/init.d/fwbuilder

Pourquoi est-il exécuté ? Il me semble que ce n'est pas l'empla cement des
"unités" ?

Le script tel quel ne passe pas car il manque les tag LSB ? Si je les raj oute
dans /etc/insserv/overrides/fwbuilder, ils seront rajoutés au script /etc/
init.d/fwbuilder, c'est ça ?

Cordialement,

PS : Mon script fwbuilder est en fait déposé dans /etc/init.d/ via ssh depuis
une autre machine.

--
David Guyot
Administrateur système, réseau et télécom / Sysadmin
Europe Camions Interactive / Stockway
Moulin Collot
F-88500 Ambacourt
03 29 30 47 85

--=-wNYhCZZkbznbR+JeL1tw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJWPMiZAAoJEAPBMoJ4TVG53t8P/3HntiDDlaXeROCKkqD0x3A8
umQOyTcpzrtwX3r/6GbcxOfzrfIl5sIkqAGSBhqOXKFBYC4jk7tIwyhZt/dXeA1k
+ngOmeT8ayIeZf2rlDXwStcRosKTvg3I7WzbYW8w1fCH5MK44huQUWsqRzAG+t00
0p6mUetHAmdmQp+63Bh/K22AdrlBaJh/KYCxyCQ9dBxnQuBQUdQQ327FNPTqmhzt
PEH373JRmXRzU9j0VpKGm0X711CataP6UP2/s7MkiNGYSIXwhNLW877+P1JdV+Al
WcCf4JB0OAY8Tu4NRwqv0UmysZ1WyNrZO+HS9+6juLPqnZ+Rx1Vtu0xW8qxXQiIw
xh3RClSly+28ErRAjLTCahkC1TIsrj7iEvFmIiIlxrCfVFe17HnAGYXHK4lCdLI1
I6Zf2wBnqWw35i7yj8rR61qY0PcBUcfKpxgGmjyG2zoH1d55Pga4uLeaMnw1dFee
cejEo6/L2IO2OSRsBPlIivqs64TbVJQ4F4vC9hR1GEzxj/qdDzP5qKcEtFGYOnmH
WHn1old/4kT0GoUhD+6yworT4ZzHIPHPja9mzwGMdwHK+bAIU8eKcbikexBcOa+z
6WP7UnYleZlS1VOvjcD0o57OAO753ULpZsxOT+95BVvFxcSkq3+HhOb04+LDxNZt
nZcKhMTSpfoq3h4Ds3Tr
=AzVe
-----END PGP SIGNATURE-----

--=-wNYhCZZkbznbR+JeL1tw--

Bonjour,

On 06/11/2015 15:52, Migrec wrote:

Je me suis documenté sur le systemd mais j'ai encore quelques question
pratiques...

Sur mon serveur mis à jour depuis peu en version stable, le nouveau systemd a
remplacé l'ancien système. J'ai un soucis avec un script "perso" qui est dans
/etc/init.d/fwbuilder

Pourquoi est-il exécuté ? Il me semble que ce n'est pas l'emplacement des
"unités" ?

Mais systemd est capable (en théorie) de gérer le démarrage etc. des scripts
sysvinit (ie des scripts dans /etc/init.d/). Donc ça semble logique ce que tu
dis.

Après dans la pratique, le peu que j'ai regardé, la prise en charge des
scripts sysvinit par systemd semble relever de la bidouille complète. Je
me rappelle avoir vu un script init.d lancé par systemd via le fichier
/etc/init.d/le-script (normal jusque là) mais le script init.d lui même
ensuite faisait appel à systemd. Bref, ça avait l'air vraiment très très
"sioux". ;)

Après, je ne fais pas partie des anti-systemd, pas du tout. Je pense
que la plupart des soucis que les gens rencontrent viennent justement
de scripts init.d dont la prise en charge de systemd me semble pas
super fiable en soi.

Bref, tout ça pour dire que si tu es sous systemd tu devrais laisser
tomber ton script init.d et utiliser systemd directement via une
une unité. Pour le coup (et c'est un des gros intérêts de systemd)
c'est vraiment très simple à écrire. Et là, tu auras une prise
en charge de ton service par systemd qui sera, je pense, correcte.

Le script tel quel ne passe pas car il manque les tag LSB ? Si je les rajoute
dans /etc/insserv/overrides/fwbuilder, ils seront rajoutés au script /etc/
init.d/fwbuilder, c'est ça ?

Pour moi, si tu veux activer un service lancé par un script init.d c'est :

update-rc.d le-service defaults

Si tu fais ça et si tu as bien tes entêtes LSB, le service devrait
bien être activé et systemd devrait normalement tentera de lancer
le service au boot. Après, comme je disais précédemment, la prise en
charge des scripts sysvinit par systemd ne me semble pas solide comme
un roc. Et force est de constater qu'au niveau des packages beaucoup
restent encore sur du sysvinit (mais c'est normal, ça se fera avec
le temps).

--
François Lafont

Re,

On 06/11/2015 17:06, Francois Lafont wrote:

Bref, tout ça pour dire que si tu es sous systemd tu devrais laisser
tomber ton script init.d et utiliser systemd directement via une
une unité. Pour le coup (et c'est un des gros intérêts de systemd)
c'est vraiment très simple à écrire. Et là, tu auras une prise
en charge de ton service par systemd qui sera, je pense, correcte.

Juste pour te donner un exemple. Sous Debian Jessie, j'ai un script
/usr/local/bin/myservice qui est une sorte de daemon dans le sens
où il ne rend jamais la main (c'est important avec systemd, apparemment
il vaut mieux que le binaire ne rende pas la main ce qui, au passage,
rend l'écriture du script encore plus facile). En gros, le script c'est
un simple :

-----------------------------
while true
do
...
done
-----------------------------

Pour faire de mon script un véritable daemon géré par systemd,
j'ai juste à créer le fichier /lib/systemd/system/myservice.service
et y mettre ceci :

-----------------------------
[Unit]
Description=My personal service
After=network.target

[Service]
User=toto
Group=toto
PIDFile=/var/lib/toto/myservice.pid
ExecStart=/usr/local/bin/myservice
Restart=on-failure

[Install]
WantedBy=multi-user.target
-----------------------------

Puis :

systemctl enable myservice # activation du démarrage automatique du service à chaque boot
systemctl start myservice # démarrage du service

Et c'est fini. C'est quand même plutôt simple je trouve.

Ceci étant je ne suis pas un expert systemd, et si j'ai dit des
bêtises, je serais ravi d'avoir vos remarques. ;)


--
François Lafont

Le Friday 06 November 2015, 18:34:22 Francois Lafont a écrit :

Pour faire de mon script un véritable daemon géré par systemd,
j'ai juste à créer le fichier /lib/systemd/system/myservice.service
et y mettre ceci :

-----------------------------
[Unit]
Description=My personal service
After=network.target

[Service]
User=toto
Group=toto
PIDFile=/var/lib/toto/myservice.pid
ExecStart=/usr/local/bin/myservice
Restart=on-failure

[Install]
WantedBy=multi-user.target
-----------------------------

Puis :

systemctl enable myservice # activation du démarrage automatique du
service à chaque boot systemctl start myservice # démarrage du servi ce

Ce qui m'embête avec cette histoire de systemd, c'est que on ne sait plus
vraiment si la config doit être dans /etc/init.d/ ou dans /lib/systemd...

Et j'ai quand même l'impression que beaucoup de paquets n'y sont pas enco re
passés (backuppc, etc.).

On 2015-11-07 22:01:30 +0100, Migrec wrote:

Ce qui m'embête avec cette histoire de systemd, c'est que on ne sait plus
vraiment si la config doit être dans /etc/init.d/ ou dans /lib/systemd...

Normalement, les paquets devraient fournir les deux, car toutes
les machines ne sont pas sous systemd.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Ci-dessous, je tente d'expliquer ce que je comprends de systemd.
Mais je découvre moi-même en ce moment alors si je dis des bêtises
j'accepte avec grand plaisir toute rectification. ;)

On 07/11/2015 22:01, Migrec wrote:

Ce qui m'embête avec cette histoire de systemd, c'est que on ne sait plus
vraiment si la config doit être dans /etc/init.d/ ou dans /lib/systemd...

Pour moi, c'est au cas par cas, en fonction du paquet. Ce que j'ai compris,
c'est que de toute façon c'est toujours systemd qui lance le service sous
Jessie, que le package propose ou non un script init.d (c'est le côté un
peu facho de systemd ;)). Ensuite, tu dois mettre la main sur le fichier
unité pour comprendre comment réellement le service est lancé. Par exemple
ssh :

~# systemctl show ssh.service | grep FragmentPath
FragmentPath=/lib/systemd/system/ssh.service

Le fichier unité est /lib/systemd/system/ssh.service et dedans on peut y
voir :

ExecStart=/usr/sbin/sshd -D $SSHD_OPTS

Donc le script init.d n'est absolument pas utilisé par le système
pour démarrer le service. systemd passe passe directement par le
binaire /usr/sbin/sshd (tu remarqueras que pourtant le paquet
openssh-server fournit bien un script init.d mais celui-ci n'est
donc pas utilisé).

Maintenant, prends par exemple le service MySQL :

~# systemctl show mysql.service | grep FragmentPath
FragmentPath=/run/systemd/generator.late/mysql.service

Le fichier unité n'est pas dans /lib/systemd mais dans /run car
c'est un fichier qui est généré (par systemd je pense) au moment
du démarrage du système. Si tu regardes ce fichier, tu verras :

ExecStart=/etc/init.d/mysql start
ExecStop=/etc/init.d/mysql stop

Là, on peut constater que le script init.d est bel et bien
utilisé par systemd pour lancer le service MySQL. C'est comme
ça, si j'ai bien compris, que systemd gère les services qui ne
démarrent qu'avec des scripts sysvinit. Et cette gestion est
d'ailleurs un peu tordue car j'ai cru comprendre qu'ensuite le
script init.d, via des inclusions de libs, fait lui-même appel
à son tour à systemd. Bref, ça semble super sioux et d'après ce
que je comprends ce n'est pas le cas idéal. Si c'est possible,
c'est bien mieux que systemd puisse démarrer un service via le
binaire directement (et avec un binaire qui ne forke pas, ie
qui ne rend pas la main).

Et j'ai quand même l'impression que beaucoup de paquets n'y sont pas encore
passés (backuppc, etc.).

C'est mon impression également. Par exemple, MySQL et Apache2 (c'est
pas n'importe quoi comme services) passent encore par une script
init.d sous Jessie. Après, j'imagine que c'est pas toujours simple
de passer le service à un démarrage via systemd. J'imagine que ça se
fera avec le temps.

Par contre, ce que je pense, c'est que si toi tu veux te créer un
petit service sous Jessie, tu as tout intérêt à le faire sans passer
par un script init.d et en utilisant un fichier unité systemd.
C'est vraiment nettement plus simple (cf mon message précédent) et
en plus je pense que ton service sera (nettement) mieux géré par
systemd dans ce cas là que si systemd doit gérer ton script init.d.

--
François Lafont

Le samedi 7 novembre 2015, 22:01:30 Migrec a écrit :

[…]
Ce qui m'embête avec cette histoire de systemd, c'est que on
ne sait plus vraiment si la config doit être dans
/etc/init.d/

Seulement si on ne veut utiliser que la compatibilité sysV.

ou dans /lib/systemd...

Plutôt dans /etc/systemd.

/lib/systemd contient la version par défaut, qui est fournie
par le paquet et qui devrait rester immuable.
/etc/systemd contient ce qui est local.

(/etc/systemd contient des liens vers /lib/systemd mais, d’aprà ¨s
ce que je comprends, ils ne sont pas nécessaires, juste
pratiques.)

--
Sylvain Sauvage

On 11/08/2015 03:42 AM, Francois Lafont wrote:

Pour moi, c'est au cas par cas, en fonction du paquet. Ce que j'ai compris,
c'est que de toute façon c'est toujours systemd qui lance le service sous
Jessie, que le package propose ou non un script init.d (c'est le côté un
peu facho de systemd ;)).

Bonjour
Précision à rectifier si besoin: l'init Systemd utilisé actuellement en
2015 par Debian a conservé un morceau de Sysvinit et il préserve la
compatibilité avec ce dernier. En conséquence, toutes les
fonctionnalités d'un "pur" Systemd ne sont pas disponibles. Il a été
officiellement annoncé chez Fedora que leur prochaine version, F24
(printemps 2016) utilisera un "pur" Systemd.

--
Maderios

On 08/11/2015 10:53, Sylvain L. Sauvage wrote:

ou dans /lib/systemd...

Plutôt dans /etc/systemd.

/lib/systemd contient la version par défaut, qui est fournie
par le paquet et qui devrait rester immuable.
/etc/systemd contient ce qui est local.

Ah, donc si on veut se créer un service hors package, on doit
mettre son fichier unité dans /etc/systemd/ pas dans /lib/systemd,
c'est bien ça ?

--
François Lafont

Le dimanche 8 novembre 2015, 12:29:24 Francois Lafont a écrit :

[…]
> /lib/systemd contient la version par défaut, qui est
> fournie par le paquet et qui devrait rester immuable.
>
> /etc/systemd contient ce qui est local.

Ah, donc si on veut se créer un service hors package, on doit
mettre son fichier unité dans /etc/systemd/ pas dans
/lib/systemd, c'est bien ça ?

Créer un service local ou modifier un service distribué : / etc
est prioritaire sur /lib (remplacer le lien dans /etc vers /lib
par un lien vers /dev/null est une façon simple de complèteme nt
arrêter, désactiver et supprimer un service).

Conserver /lib « brut de dépaquetage » peut aussi faci liter la
vie de l’admin (sauvegarde, gestion des màj…).

Après, chacun fait ce qui lui plaît…

--
Sylvain Sauvage