Systemd et scripts /etc/init.d/.
Le
Migrec
Bonjour,
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 syste=
md a
remplacé l'ancien système. J'ai un soucis avec un script "perso" qui es=
t dans
/etc/init.d/fwbuilder
Pourquoi est-il exécuté ? Il me semble que ce n'est pas l'emplacement d=
es
"unités" ?
Le script tel quel ne passe pas car il manque les tag LSB ? Si je les rajou=
te
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.
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 syste=
md a
remplacé l'ancien système. J'ai un soucis avec un script "perso" qui es=
t dans
/etc/init.d/fwbuilder
Pourquoi est-il exécuté ? Il me semble que ce n'est pas l'emplacement d=
es
"unités" ?
Le script tel quel ne passe pas car il manque les tag LSB ? Si je les rajou=
te
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.
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 :
--
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--
On 06/11/2015 15:52, Migrec wrote:
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.
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
On 06/11/2015 17:06, Francois Lafont wrote:
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
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.).
Normalement, les paquets devraient fournir les deux, car toutes
les machines ne sont pas sous systemd.
--
Vincent Lefèvre 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
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:
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).
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
Seulement si on ne veut utiliser que la compatibilité sysV.
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
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
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
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