CentOS 7 démarre trop rapidement et le réseau n'est pas prêt lors de l'exécution des scripts cron


9

Je viens de passer de CentOS 6.5 à 7.0 et je ne suis pas trop content car le nouveau systemdme pose probablement des problèmes. Il semble qu'il démarre simplement trop vite, démarre des processus de manière asynchrone et fout les dépendances de service.

Par exemple, j'ai quelques scripts de configuration dans crondlesquels sont déclenchés après un redémarrage:

@reboot    /root/scripts/check_gmail.sh
@reboot    /root/scripts/start_gps_listener.sh

Il en résulte toutes sortes d'erreurs étranges (ne montrant qu'une seule d'entre elles):

Warning: stream_socket_client(): unable to connect to tcp://192.168.20.4:4001 
  (Network is unreachable) in /root/scripts/check_gmail.php on line 137
  ERROR: Network is unreachable (101)

Dans ce qui précède, j'écris sur un socket TCP. Il est assez clair pour moi que cela cronddémarre avant que le réseau ne soit correctement initialisé en tant que network is unreachable.

La même chose va avec Apache et MySQL (MariaDB). MySQL est assez lent au démarrage (beaucoup de données), ce qui signifie qu'Apache et beaucoup de mes crondscripts de démarrage échouent car la base de données MySQL ne fonctionne pas lors de l'appel des scripts.

J'ai essayé de configurer des dépendances mais sans aucune chance; J'ai annexé networket mysqlservices à [Unit](comme vu avec systemctl list-dependencies). Idéalement, tous les services attendent que MySQL soit opérationnel:

vi /lib/systemd/system/httpd.service
  [Unit]
  Description=The Apache HTTP Server
  After=network.target remote-fs.target nss-lookup.target network.service mysql.service

vi /lib/systemd/system/crond.service
  [Unit]
  Description=Command Scheduler
  After=syslog.target auditd.service systemd-user-sessions.service time-sync.target network.service mysql.service

Lors du démarrage avec ce qui précède, j'obtiens les mêmes erreurs. Je reçois également les e-mails mailqcar le réseau / DNS n'est pas prêt lors du traitement des cron-scripts. Quelques minutes après le démarrage, ils sont envoyés correctement.

Quelqu'un peut-il aider à bien faire les choses en s'assurant que les services sont lancés dans le bon ordre? Il semble très erroné que le démarrage soit si rapide et, idéalement, il l'a fait à l'ancienne: "lancement d'un service ... attendez ... lancez un nouveau service ... attendez ... ainsi de suite).

Notez que je ne suis pas sûr systemdque ce soit mon problème - c'est juste ma théorie de ce que je peux lire sur le net.


Pourriez-vous publier la sortie de grep -i concurrency /etc/default/rcS? Je suis peut-être en train de mélanger mes systèmes d'initialisation, mais je semble me rappeler que contrôle si les processus attendent la fin les uns des autres.
terdon

Je n'ai aucun fichier avec/etc/default/rc*
DHS

Désolé, je ne sais pas où serait l'équivalent de CentOS. Je pensais à ce qui est décrit ici pour Debian, ce qui fait démarrer les services en parallèle. Il pourrait y avoir quelque chose de similaire dans votre cas.
terdon

2
Essayez d'ajouter Requires=network.targetaux unités ci-dessus.
casey

Toujours le même problème après avoir été inséré Requires=network.targetdans/lib/systemd/system/crond.service
DHS

Réponses:


9

Après beaucoup plus de lecture, j'ai trouvé la solution qui me convient.

J'ai lu ce guide, Exécution des services une fois le réseau activé . Une petite citation du guide:

Cela garantira que tous les périphériques réseau configurés sont en place et qu'une adresse IP est attribuée avant que le démarrage se poursuive.

C'est exactement ce que je voulais, j'ai donc activé ce service et défini la règle de dépendance dans le fichier de service pour crond:

[root@srv]# systemctl enable NetworkManager-wait-online

[root@srv]# vi /lib/systemd/system/crond.service
  Requires=network.target
  After=syslog.target auditd.service systemd-user-sessions.service time-sync.target network.target mysqld.service

Comme il mysqldest toujours basé sur l'ancien dont init.dj'avais besoin pour créer un systemdservice comme suggéré ici, l' activation de systemctl diffère du démarrage de systemctl :

[root@srv]# vi /lib/systemd/system/mysqld.service
  [Unit]
  Description=MySQL Server
  After=network.target
  [Service]
  Type=forking
  ExecStart=/etc/rc.d/init.d/mysql start
  ExecStop=/etc/rc.d/init.d/mysql stop
  [Install]
  WantedBy=multi-user.target

[root@srv]# systemctl daemon-reload
[root@srv]# chkconfig mysql off
[root@srv]# systemctl enable mysqld

Et enfin, configurez le service Apache pour démarrer après MySQL:

[root@srv]# vi /lib/systemd/system/httpd.service
  Requires=mysqld.service
  After=network.target remote-fs.target nss-lookup.target mysqld.service

Cela fonctionne pour moi au moins.

J'ai utilisé ces commandes pour vérifier ensuite où je peux clairement voir que le réseau est démarré avant au moins MySQL et Apache. Je ne peux cependant pas voir crondnulle part mais je peux voir que cela fonctionne dans mes scripts:

[root@srv]# systemd-analyze critical-chain
  multi-user.target @10.510s
    + httpd.service @10.344s +165ms
      + mysqld.service @9.277s +1.065s
        + network.target @9.273s
          + network.service @8.917s +355ms
            + iptables.service @444ms +157ms
              + basic.target @443ms
                [CUT]

Quelques autres commandes utiles que j'ai utilisées sont:

# See exactly what takes how long (who to blame for the delay)
[root@srv]# systemd-analyze blame

# Check available names that can be used in the service files
[root@srv]# systemctl list-unit-files

Si quelqu'un peut voir une meilleure façon de procéder, veuillez partager.


+1 pour avoir publié les commandes que vous avez utilisées pour déboguer cela. J'ai pu résoudre un nœud de problèmes vraiment désagréable systemd-analyze critical-chain. Non seulement je vais l'utiliser souvent, mais je suis soudainement vendu systemd. Merci!
Brian Topping

Vous ne devez pas modifier les fichiers de services gérés par votre gestionnaire de packages de distribution. Au lieu de cela, vous feriez mieux d'utiliser des fichiers de configuration intégrés. Voir la réponse à Comment remplacer ou configurer les services systemd?
Ludovic Ronsin
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.