CentOS 7 si avvia troppo velocemente e la rete non è pronta durante l'esecuzione degli script cron


9

Ho appena effettuato l'aggiornamento da CentOS 6.5 a 7.0 e non sono contento perché il nuovo systemdprobabilmente mi sta dando problemi. Sembra che si stia semplicemente avviando troppo velocemente, avviando i processi in modo asincrono e rovinando le dipendenze del servizio.

Ad esempio ho alcune impostazioni di script in crondcui vengono attivate dopo un riavvio:

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

Ciò si traduce in tutti i tipi di strani errori (mostrandone solo uno):

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)

In quanto sopra sto scrivendo su un socket TCP. È abbastanza chiaro per me che crondviene avviato prima che la rete venga inizializzata correttamente come network is unreachable.

La stessa cosa vale per Apache e MySQL (MariaDB). MySQL è piuttosto lento all'avvio (molti dati), il che significa che sia Apache che molti dei miei crondscript di avvio non funzionano poiché il database MySQL non è in esecuzione quando vengono chiamati gli script.

Ho provato a configurare le dipendenze ma senza fortuna; Ho aggiunto networke mysqlservizi a [Unit](come visto con systemctl list-dependencies). Idealmente tutti i servizi attendono che MySQL sia attivo e funzionante:

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

Quando si avvia con quanto sopra ottengo gli stessi errori. Ricevo anche le e-mail in mailqquanto la rete / DNS non è pronta durante l'elaborazione dei cron-script. Pochi minuti dopo l'avvio vengono inviati correttamente.

Qualcuno può aiutare a farlo bene assicurandosi che i servizi siano attivati ​​nell'ordine corretto? Sembra molto sbagliato che si avvii così velocemente e idealmente lo ha fatto alla vecchia maniera, "lanciando un servizio ... aspetta ... lanciando un nuovo servizio ... aspetta ... ecc.).

Nota che non sono sicuro che sia systemdquesto il mio problema: è solo la mia teoria di ciò che posso leggere dalla rete.


Potresti pubblicare l'output di grep -i concurrency /etc/default/rcS? Potrei confondere i miei sistemi di inizializzazione, ma mi sembra di ricordare che controlla se i processi aspettano che finiscano l'un l'altro.
terdon

Non ho file con/etc/default/rc*
DHS

Spiacente, non so dove sarebbe l'equivalente di CentOS. Stavo pensando a ciò che è descritto qui per Debian, che fa iniziare i servizi in parallelo. Potrebbe esserci qualcosa di simile nel tuo caso.
terdon

2
Prova ad aggiungere Requires=network.targetalle unità sopra.
Casey,

Ancora lo stesso problema dopo essere stato inserito Requires=network.targetin/lib/systemd/system/crond.service
DHS il

Risposte:


9

Dopo molte più letture ho trovato la soluzione che funziona per me.

Ho letto questa guida, Running Services After the Network is up . Una piccola citazione dalla guida:

Ciò garantirà che tutti i dispositivi di rete configurati siano attivi e che sia assegnato un indirizzo IP prima che l'avvio continui.

Questo è esattamente quello che volevo, quindi ho abilitato questo servizio e ho impostato una regola di dipendenza nel file di servizio per 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

Poiché mysqldè ancora basato sul vecchio, init.davevo bisogno di creare un systemdservizio come suggerito qui, l'abilitazione di systemctl differisce da start di 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

E infine imposta il servizio Apache all'avvio dopo MySQL:

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

Questo funziona almeno per me.

Ho usato questi comandi per controllarlo in seguito dove posso vedere chiaramente che la rete è stata avviata prima almeno di MySQL e Apache. Tuttavia, non riesco a vedere da crondnessuna parte, ma vedo che sta funzionando nei miei script:

[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]

Un paio di altri comandi utili che ho usato sono:

# 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

Se qualcuno può vedere un modo migliore per farlo, per favore condividi.


+1 per pubblicare i comandi che hai usato per eseguire il debug. Sono stato in grado di risolvere un nodo davvero brutto di problemi systemd-analyze critical-chain. Non solo lo userò spesso, ma all'improvviso vengo venduto systemd. Grazie!
Brian Topping

Non è necessario modificare i file dei servizi gestiti dal gestore dei pacchetti di distribuzione. Invece è meglio usare i file di configurazione drop-in. Vedi la risposta a Come posso sovrascrivere o configurare i servizi di systemd?
Ludovic Ronsin,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.