Exécuter script d'init en dernier

Tags: #<Tag:0x00007f509df41790> #<Tag:0x00007f509df41678> #<Tag:0x00007f509df415b0>

Salut à tous !

J’ai un problème qui doit être tout bête, avec un script d’init. L’exécution de ce script dépend de mysql, et j’aimerais donc forcément qu’il soit exécuté après le script d’init de mysql. J’ai lu dans la doc qu’il suffirait normalement d’indiquer

# Required-Start:    $all
# Required-Stop:     $all

dans l’en-tête du script, pour que celui-ci soit lancé à la toute fin de la séquence d’init. Or, malgré cette précaution, systemctl status mon_script me renvoie :

Jul 17 07:17:16 monserveur mon_script.sh[427]: SQLException: Failed to start connection pool -- Can't connect to MySQL server on '127.0.0.1' (111)
Jul 17 07:17:16 monserveur mon_script.sh[427]: raised in ConnectionPool_start at src/db/ConnectionPool.c:287

Ce qui me fait penser que mon script d’init n’a pas attendu sagement le lancement du serveur MySQL. Le script en lui-même m’a l’air OK, puisque si je lance à la main systemctl restart mon_script après le démarrage, tout se passe comme attendu (lancement de mes services dépendant de MySQL).

Une idée ?

Ça peut ne pas paraître propre, mais moi, quand j’ai un script à lancer après que les services soient lancés, je le lance à partir du script /etc/rc.local.
Il y a probablement beaucoup plus propre à faire depuis l’avènement de systemd dans Debian, mais je n’ai pas eu envie, pour le moment, de me pencher dessus. Si la réponse vient à passer dans ce sujet, j’en serais très content parce que ça m’intéresse aussi.

Comment as-tu enregistré le script pour qu’il s’exécute au démarrage ? Avec update-rc.d ?
Tu peux vérifier les numéros d’ordre respectifs de ton script et de celui de MySQL dans /etc/rc2.d/.

Ah, mais c’est l’ancien système ça, ça fonctionne toujours avec systemd grâce à une compatibilité, mais ce n’est pas la méthode pour systemd, de même que pour ma méthode de lancer le script via /etc/rc.local.

Ach, effectivement après vérification il va falloir que je me mette 100% à systemd. Explications :

  • Dans mon /etc/rc2.d, mysql démarre en S02 et mon script en S04. Ça donne l’impression que tout devrait bien se passer (et ça confirme que mon en-tête a bien été pris en compte).

  • En revanche, un systemd-analyze plot m’indique que mon script a démarré quelques millisecondes avant mysql.

Je vais donc de ce pas me convertir aux fichiers services de systemd :frowning:. Je vous donnerai des nouvelles !

Bon, ben c’était bien ça. Pour info, les sources dont je me suis inspiré pour migrer mon script vers systemd :

  1. http://unix.stackexchange.com/questions/47695/how-to-write-startup-script-for-systemd
  2. http://linuxfr.org/news/systemd-pour-les-administrateurs-parties-3-4-et-5

Merci pour les pistes :slight_smile:.

A mon avis ce n’est pas normal. systemd devrait respecter l’ordre d’exécution des initscripts.

C’est bien ce qu’il me semblait aussi, notamment et surtout pendant la période de transition qu’on traverse. Et il semblerait que ce soit le cas pour les scripts init fournis par des paquets Debian. C’est donc peut-être moi qui ai shunté une étape ? :confused:

Édit : pour répondre à ta question plus haut, d’ailleurs, oui j’ai “installé” le script d’init avec update-rc.d. L’en-tête complet de feu le script d’init, si ça peut aider :

#! /bin/sh

### BEGIN INIT INFO
# Provides:          mon_script
# Required-Start:    $all
# Required-Stop:     $all
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Bla
# Description:       Bla bla
### END INIT INFO

et avec un CRON «@startup» ça n’aurait pas suffit ?

Non, pour deux raisons :

  1. Le script est un peu complexe pour un cron (lancement de plusieurs services)
  2. Je veux avoir une interface pour faire du start, stop, restart quand j’en ai besoin et éventuellement monitorer l’état du service (après que ce soit systemctl ou service, …)

Non, pas si systemd a un ordre différent dans ses paramètres. Je croyais aussi, mais je me suis ravisé quand j’ai vu que, en fait, non.

Je déterre un peu pour rapporter le message d’avertissement qui vient avec la dernière version packagée de systemd (dans unstable pour l’instant) :

systemd (231-1) unstable; urgency=low

This version drops support for running /etc/rcS.d SysV init scripts.
These are prone to cause dependency loops, and almost all Debian packages
with rcS scripts now ship a native systemd service. If you have custom or
third-party rcS scripts you need to convert them; see this page for
details: https://wiki.debian.org/Teams/pkg-systemd/rcSMigration.

– Martin Pitt mpitt@debian.org Thu, 14 Jul 2016 12:54:34 +0200