O CentOS 7 inicializa muito rápido e a rede não está pronta ao executar scripts cron

9

Acabei de atualizar do CentOS 6.5 para o 7.0 e não estou muito feliz, pois o novo systemd provavelmente está me dando problemas. Parece que é simplesmente inicializar muito rápido, iniciar processos de forma assíncrona e estragar as dependências do serviço.

Por exemplo, tenho alguns scripts configurados em crond , que são acionados após uma reinicialização:

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

Isso resulta em todos os tipos de erros estranhos (mostrando apenas um deles):

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)

Acima, estou escrevendo para um soquete TCP. É bem claro para mim que crond é iniciado antes que a rede seja inicializada corretamente como network is unreachable .

O mesmo acontece com o Apache e o MySQL (MariaDB). O MySQL é muito lento para a inicialização (muitos dados), o que significa que o Apache e muitos dos meus scripts de inicialização crond estão falhando, pois o banco de dados MySQL não está em execução quando os scripts estão sendo chamados.

Eu tentei configurar dependências, mas sem sorte; Eu adicionei network e mysql services a [Unit] (como visto com systemctl list-dependencies ). O ideal é que todos os serviços esperem até que o MySQL esteja funcionando:

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

Ao inicializar com o anterior, recebo os mesmos erros. Também recebo os emails em mailq porque a rede / DNS não está pronta ao processar scripts cron. Alguns minutos após a inicialização, eles são enviados corretamente.

Alguém pode ajudar a acertar isso, certificando-se de que os serviços são disparados na ordem correta? Parece muito errado que ele seja tão rápido de inicializar e, idealmente, tenha sido feito da maneira antiga, " um seriço ... espera ... lançando um novo serviço ... espera ... assim por diante).

Observe que não tenho certeza se é systemd , e isso é problema meu - é apenas minha teoria sobre o que posso ler na Internet.

    
por DHS 31.10.2014 / 16:46

1 resposta

9

Depois de ler muito mais, encontrei a solução que funciona para mim.

Eu li este guia, Serviços em execução após a conclusão da rede . Uma pequena citação do guia:

This will ensure that all configured network devices are up and have an IP address assigned before boot continues.

Isso é exatamente o que eu queria, então ativei este serviço e defini a regra de dependência no arquivo de serviço para 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

Como mysqld ainda é baseado no antigo init.d , precisei criar um serviço systemd como sugerido aqui, systemctl enable difere do início do 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 finalmente configure o serviço Apache para a inicialização após MySQL:

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

Isso funciona para mim pelo menos.

Eu usei esses comandos para verificá-lo posteriormente, onde eu posso ver claramente que a rede foi iniciada antes de pelo menos o MySQL e o Apache. Eu não consigo ver o crond em qualquer lugar, mas posso ver que está funcionando nos meus 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]

Alguns outros comandos úteis que usei são:

# 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 alguém puder ver uma maneira melhor de fazer isso, compartilhe.

    
por 31.10.2014 / 21:05