CentOS 7 завантажується занадто швидко і мережа не готова під час виконання скриптів cron

Я щойно оновив з CentOS 6.5 до 7.0, і я не надто задоволений, оскільки нове systemd, напевно, створює мені проблеми. Здається, що це просто завантаження занадто швидко, запуск процесів асинхронно та усунення залежностей від служби.

Наприклад, у мене є кілька налаштувань сценаріїв, crondякі спрацьовують після перезавантаження:

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

Це призводить до різного роду дивних помилок (відображається лише одна з них):

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)

У вищесказаному я пишу в сокет TCP. Мені досить зрозуміло, що crondзапускається до того, як мережа буде належним чином ініціалізована як network is unreachable.

Те саме стосується Apache та MySQL (MariaDB). MySQL досить повільний до запуску (багато даних), що означає, що і Apache, і багато моїх crondсценаріїв запуску не вдається, оскільки база даних MySQL не працює при виклику скриптів.

Я намагався встановити залежності, але без жодної удачі; Я додав networkі mysqlпослуги [Unit](як видно з systemctl list-dependencies). В ідеалі всі сервіси чекають запуску та запуску MySQL:

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

Під час завантаження з вищезазначеним я отримую однакові помилки. Я також отримую електронні листи, mailqоскільки мережа / DNS не готова під час обробки cron-скриптів. Через кілька хвилин після запуску вони надсилаються правильно.

Чи може хтось допомогти отримати це право, переконавшись, що послуги працюють у правильному порядку? Дуже неправильно здається, що це таке швидке завантаження, і в ідеалі це зробило це старим добрим способом, "запустивши один сервіс ... зачекайте ... запустивши нову послугу ... почекайте ... і так далі".

Зауважте, що я не впевнений, systemdщо це моя проблема - це лише моя теорія того, що я можу прочитати з мережі.

Після багато іншого читання я знайшов рішення, яке працює для мене.

Я прочитав цей посібник, Запуск служб після того, як мережа працює . Маленька цитата з путівника:

Це забезпечить всі налаштовані мережеві пристрої в режимі роботи та матиме IP-адресу перед продовженням завантаження.

Це саме те, що я хотів, тому я включив цю послугу і встановив правило залежності в сервісному файлі для 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

Як mysqldі досі базується на старому, що init.dмені потрібно було створити systemdслужбу, як запропоновано тут, включення systemctl відрізняється від запуску 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

І нарешті налаштуйте сервіс Apache для запуску після MySQL:

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

Це працює принаймні для мене.

Я використовував ці команди, щоб потім перевірити їх, де я чітко бачу, що мережа запускається до принаймні MySQL та Apache. Я хоч і crondніде не бачу, але можу бачити, що він працює в моїх сценаріях:

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

Кілька інших корисних команд, які я використав:

# 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

Якщо хтось може побачити кращий спосіб зробити це, будь ласка, поділіться.