Systemctl перезапуск при ошибке

Иногда сервисы ни с того ни с сего падают и приходиться их вручную восстанавливать. Если для пользователя домашнего компьютера это не критично, потому что если сервис падает во время разработки, то это даже хорошо, можно сразу увидеть что есть проблема. Но на серверах и VPS сервисы должны работать постоянно для обеспечения доступа к веб-сайту или приложению.

В этой инструкции я покажу как настроить автоматический перезапуск сервиса Linux несколькими способами: с помощью скрипта мониторинга периодически запускаемого через cron и в systemd.

Автоматический перезапуск сервиса в systemd

По умолчанию, если ваш сервис будет убит или завершится некорректно, systemd не будет с ним ничего делать. Но можно настроить сервис так, чтобы при падении или даже остановке он автоматически перезапускался. Для этого используется директива Restart, которую надо добавить в секцию Service. Этот параметр может иметь такие значения:

  • on-failure — только если произошла ошибка;
  • on-success — только если процесс сервиса завершился без ошибок;
  • on-abnormal — только если сервис не отвечает;
  • always — перезапускать всегда, когда сервис был остановлен;

 Например, рассмотрим настройку автоматического перезапуска сервиса Apache:

sudo systemctl edit apache2

[Service]
Restart=on-failure
RestartSec=5s

Директива RestartSec указывает сколько ждать перед перезапуском сервиса. Когда завершите сохраните изменения и выполните команду daemon-reload, чтобы перечитать конфигурацию:

sudo systemctl daemon-reload

Затем чтобы проверить что всё работает посмотрите состояние процесса, завершите процесс сигналом kill:

sudo systemctl status apache2

kill -KILL 32091

И снова посмотрите состояние. Процесс будет запущен. Система инициализации автоматически перезапустит его как только он завершится с кодом возврата ошибки. Если вы хотите чтобы процесс перезапускался всегда, необходимо использовать директиву Restart: always. Однако с ней надо быть осторожным, она вовсе не даст вам завершить процесс, даже если будет необходимо. Для того, чтобы процесс, который постоянно падает не перезапускался, можно добавить лимит на количество перезапусков в секцию Service:

sudo systemctl edit apache2

[Service]
StartLimitIntervalSec=500
StartLimitBurst=5
Restart=on-failure
RestartSec=5s

Директивы StartLimitBurst и StartLimitIntervalSec указывают, что надо попытаться перезапустить сервис пять раз, и если он все эти пять раз упадёт, то больше его не трогать. Вторая директива ограничивает время перезапусков сервиса до 500 секунд.

Автоматический перезапуск сервиса с помощью скрипта

Это самый простой и самый надежный способ работающий абсолютно во всех дистрибутивах Linux и не требующий установки дополнительных утилит. Для того же Apache скрипт выглядит следующим образом:

sudo vi /usr/local/bin/apache-monitor.sh

#!/bin/bash
ps -A | grep apache2 || systemctl start apache2

Сохраните файл, сделайте его исполняемым:

chmod ugo+x /usr/local/bin/apache-monitor.sh

Теперь добавьте запись в cron для периодического запуска скрипта:

sudo crontab -e

*/5 * * * * /usr/local/bin/apache-monitor.sh

На этом все, автоматический перезапуск сервисов штука может и немного сложная, но необходимая в серьезных системах.

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

Creative Commons License

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .

Об авторе

Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.

Как в Linux пользоваться systemctl и systemd

Обновлено Обновлено: 15.04.2022
Опубликовано Опубликовано: 06.09.2016

Вместе с подсистемой systemd появилась команда systemctl. Она позволяет управлять основными процессами Linux. Ниже представлена небольшая инструкция в виде шпаргалки наиболее используемых команд.

Описание команды systemctl
Примеры ее использования
Как с помощью systemd настроить автозапуск
Таймеры

Общий синтаксис

Без параметров, systemctl показывает список запущенных служб, точек монтирования, устройств и других юнитов.

# systemctl

Примерный вывод команды:

Вывод команды systemctl

1) название юнита;
2) тип юнита (например, service: служба или демон, mount: точка монтирования, device: устройства);
3) состояние юнита (загружен или нет);
4) обобщенный статус юнита (active: выполняется, inactive: не был запущен, maintenance: требуется внимание администратора);
5) текущий статус (запущен или нет);
6) описание.

1. Посмотреть статус службы:

systemctl status network

* покажет статус службы на примере сети network

2. Запустить сервис:

systemctl start mysql

* запустит сервис баз данных на примере mysql

3. Остановить службу:

systemctl stop ntpd

* остановит сервис времени ntpd

4. Перезапустить службу:

systemctl restart nginx

* перезапустит веб-сервер nginx

5. Включить автозапуск службы:

systemctl enable apache

* разрешит автозапуск веб-сервера apache

6. Отключить автозапуск службы:

systemctl disable firewalld

* запретит автозапуск брандмауэра firewalld

7. Выполнить команду на удаленной системе:

systemctl —host root@192.168.0.15 stop cron

* остановит cron на компьютере с IP-адресом 192.168.0.15, подключившись под учетной записью root.

8. Перезагрузить сервер:

systemctl reboot

* перезагрузит локальный сервер.

9. Проверка работы сервиса.

Выполняется с помощью опции is-active:

systemctl is-active docker

* в данном примере мы проверим работу службы docker.

а) Если сервис запущен, мы увидим:

active

б) Если не запущен:

failed

… или:

inactive

в) Если такого сервиса нет в системе:

unknown

… или:

inactive

Если сервис не работает или его нет в системе, команда вернет код ошибки, таким образом конструкция:

systemctl is-active docker && docker run hello-world

… приведет к выполнению команды docker run hello-world только в том случае, если сервис docker работает.

Автозапуск

Подсистему systemd также можно использовать для автозапуска сервисов или скриптов. Для этого в каталоге /usr/lib/systemd/system создаем юнит (файл) с расширением .service. Подробнее разберем на примере сервиса bind:

vi /usr/lib/systemd/system/named.service

Содержимое может быть следующего содержания:

[Unit]
Description=Berkeley Internet Name Domain (DNS)
Wants=nss-lookup.target
Wants=named-setup-rndc.service
Before=nss-lookup.target
After=network.target
After=named-setup-rndc.service

[Service]
Type=forking
Environment=NAMEDCONF=/etc/named.conf
EnvironmentFile=-/etc/sysconfig/named
Environment=KRB5_KTNAME=/etc/named.keytab
PIDFile=/run/named/named.pid
ExecStartPre=/bin/bash -c ‘if [ ! «$DISABLE_ZONE_CHECKING» == «yes» ]; then /usr/sbin/named-checkconf -z «$NAMEDCONF»; else echo «Checking of zone files is disabled»; fi’
ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS
ExecReload=/bin/sh -c ‘/usr/sbin/rndc reload > /dev/null 2>&1 || /bin/kill -HUP $MAINPID’
ExecStop=/bin/sh -c ‘/usr/sbin/rndc stop > /dev/null 2>&1 || /bin/kill -TERM $MAINPID’
PrivateTmp=true

[Install]
WantedBy=multi-user.target

* как правило, файл разделен на 3 части:

  • Unit — позволяет определить метаданные для юнита.
  • Service — раздел для основной конфигурации юнита.
  • Install — определение поведения для юнита при его включении или отключении.

Подробнее можно почитать о структуре и возможных опциях на странице https://linux-notes.org/pishem-systemd-unit-fajl/

После внесения изменений и сохранения файла, необходимо перечитать изменения командой:

systemctl daemon-reload

Теперь можно разрешить автозапуск:

systemctl enable named

Редактирование сервисов

Если мы хотим внести изменения в юнит-файл сервиса, который был установлен с последним, необходимо использовать drop-in файл или файл переопределения настроек. В противном случае, после обновления программы наши изменения могут быть удалены.

И так, мы для примера взяли юнит для bind. Чтобы создать для него drop-in файл, вводим:

systemctl edit named

И вносим, например, такие изменения:

[Service]
Restart=on-failure

* будет создан файл /etc/systemd/system/named.service.d/override.conf, который будет переопределять настройки основного юнит-файла. В данном примере, мы указываем на необходимость перезапуска сервиса при сбое.

Чтобы убедиться в использовании Drop-In файла смотрим статус сервиса:

systemctl status named

Мы должны увидеть что-то на подобие:

Drop-In: /etc/systemd/system/named.service.d
           — override.conf

Таймеры

Выше мы рассмотрели возможность автоматического запуска сервисов с помощью systemd. Мы также можем настроить периодический запуск данных юнитов по таймеру. Для этого нам нужно создать юнит с таким же названием, но на конце должен быть суффикс .timer.

Предположим, мы хотим создать запуск по таймеру named, для которого выше в примере создали юнит сервиса. Тогда создаем файл:

vi /usr/lib/systemd/system/named.timer

[Unit]
Description=Run named every 10 min

[Timer]
OnBootSec=5min
OnUnitActiveSec=10min

[Install]
WantedBy=timers.target

* в данном примере наш таймер будет создан для юнита named; он запустится через 5 минут после старта службы и будет запускать ее каждые 10 минут.

Перечитаем изменения в systemd:

systemctl daemon-reload

Разрешаем наш таймер:

systemctl enable named.timer

Запустим его:

systemctl start named.timer

Вывести список таймеров можно командой:

systemctl list-timers

There are many reasons for systemd crash/go down on Linux, which you can investigate and fix ,but it is time consuming.

One thing you can do it immediately to bring the service back to online is  auto start when it goes down, which eventually reduce the downtime for better availability and to make sure that your service will be always available for users access.

It’s very easy to automate this on systemd systems because it has an options to enable this.

It can be done by bash script. We already had developed a bash script to automatically start a services when it’s crash on Linux.

What is systemd?

Systemd is a new init system and system manager which was implemented/adapted into all the major Linux distributions over the traditional SysV init systems.

systemd is compatible with SysV and LSB init scripts. It can work as a drop-in replacement for sysvinit system.

systemd is the first process which will  get started by kernel and holding PID 1.

It’s a parent process for everything and Fedora 15 is the first distribution which was adapted systemd instead of upstart.

systemctl is a command line utility and primary tool to manage the systemd daemons/services such as (start, restart, stop, enable, disable, reload & status).

systemd uses .service files Instead of bash scripts (SysV init uses). systemd sorts all daemons into their own Linux cgroups and you can see the system hierarchy by exploring /cgroup/systemd file.

The systemd service file has three major parts and we need to add the below required parameters under [Service] potion.

[Unit]
...

[Service]
Restart=on-failure
RestartSec=5s
...

[Install]
...
  • Restart: Configures whether the service shall be restarted when the service process exits, is killed, or a timeout is reached.
  • on-failure: If set to on-failure, the service will be restarted when the process exits with a non-zero exit code, is terminated by a signal, when an operation (such as service reload) times out, and when the configured watchdog timeout is triggered.
  • RestartSec: Configures the time to sleep before restarting a service. Takes a unit-less value in seconds, or a time span value such as “5min 20s”. Defaults to 100ms.
  • 5s: It will wait for 5 sec then start the service.

How to add Auto Start service parameter in systemd System?

It’s not a big deal to add these parameters. Open the corresponding service file and append the following parameters.

To explain this, we are going to test httpd service. Let’s see this.

# vi /etc/systemd/system/multi-user.target.wants/httpd.service

[Unit]
Description=Apache Web Server
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=simple
ExecStart=/usr/bin/httpd -k start -DFOREGROUND
ExecStop=/usr/bin/httpd -k graceful-stop
ExecReload=/usr/bin/httpd -k graceful
PrivateTmp=true
LimitNOFILE=infinity
KillMode=mixed
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

You need to reload the daemon service once you made the changes. You can see the same by running the “systemctl status [httpd]” command as shown below.

We could see that, it is marked in color for better visibility. Also, the Apache httpd web server was started 27 mins ago.

# systemctl status httpd

● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2019-08-05 16:45:24 CDT; 27min ago
     Docs: man:httpd(8)
           man:apachectl(8)
  Process: 14420 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE)
Main PID: 14424 (httpd)
   Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"
   CGroup: /system.slice/httpd.service
           ├─14424 /usr/sbin/httpd -DFOREGROUND
           ├─14425 /usr/sbin/httpd -DFOREGROUND
           ├─14426 /usr/sbin/httpd -DFOREGROUND
           ├─14427 /usr/sbin/httpd -DFOREGROUND
           ├─14428 /usr/sbin/httpd -DFOREGROUND
           └─14429 /usr/sbin/httpd -DFOREGROUND

Aug 05 16:45:23 thvtstrhl7 systemd[1]: Stopped The Apache HTTP Server.
Aug 05 16:45:23 thvtstrhl7 systemd[1]: Starting The Apache HTTP Server...
Aug 05 16:45:24 thvtstrhl7 systemd[1]: Started The Apache HTTP Server.
Warning: httpd.service changed on disk. Run 'systemctl daemon-reload' to reload units.

Just reload the daemon service.

# systemctl daemon-reload

This will go off now. It can be verified by running the following command once again.

# systemctl status httpd

● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2019-08-05 16:45:24 CDT; 27min ago
     Docs: man:httpd(8)
           man:apachectl(8)
Main PID: 14424 (httpd)
   Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"
   CGroup: /system.slice/httpd.service
           ├─14424 /usr/sbin/httpd -DFOREGROUND
           ├─14425 /usr/sbin/httpd -DFOREGROUND
           ├─14426 /usr/sbin/httpd -DFOREGROUND
           ├─14427 /usr/sbin/httpd -DFOREGROUND
           ├─14428 /usr/sbin/httpd -DFOREGROUND
           └─14429 /usr/sbin/httpd -DFOREGROUND

Aug 05 16:45:23 thvtstrhl7 systemd[1]: Stopped The Apache HTTP Server.
Aug 05 16:45:23 thvtstrhl7 systemd[1]: Starting The Apache HTTP Server...
Aug 05 16:45:24 thvtstrhl7 systemd[1]: Started The Apache HTTP Server.

To experiment this, use pidof command to find out the PID of a process. We can find out the process id (PID) in Linux using nine ways.

# pidof httpd

14429 14428 14427 14426 14425 14424

Once you get the PID details, just kill them all together in one go using the following command. There are many similar commands are available in Linux to Kill a Process ID (PID).

# kill -9 14429 14428 14427 14426 14425 14424

Once you killed the httpd PID, just run the following command to see the status. It’s showing the service is getting auto-restart. But still it’s not up.

# systemctl status httpd

● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: activating (auto-restart) (Result: exit-code) since Mon 2019-08-05 17:14:26 CDT; 2s ago
     Docs: man:httpd(8)
           man:apachectl(8)
  Process: 15978 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE)
  Process: 14424 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=killed, signal=KILL)
Main PID: 14424 (code=killed, signal=KILL)
   Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"

Aug 05 17:14:26 thvtstrhl7 systemd[1]: httpd.service: control process exited, code=exited status=1
Aug 05 17:14:26 thvtstrhl7 systemd[1]: Unit httpd.service entered failed state.
Aug 05 17:14:26 thvtstrhl7 systemd[1]: httpd.service failed.

Let me run the above command once again and see how the results looks. Yup, awesome, it’s running now. it’s working as expected.

It was started 564 Millisecond sec ago.

# systemctl status httpd

● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2019-08-05 17:14:31 CDT; 564ms ago
     Docs: man:httpd(8)
           man:apachectl(8)
  Process: 15978 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE)
Main PID: 15987 (httpd)
   Status: "Processing requests..."
   CGroup: /system.slice/httpd.service
           ├─15987 /usr/sbin/httpd -DFOREGROUND
           ├─15988 /usr/sbin/httpd -DFOREGROUND
           ├─15989 /usr/sbin/httpd -DFOREGROUND
           ├─15990 /usr/sbin/httpd -DFOREGROUND
           ├─15991 /usr/sbin/httpd -DFOREGROUND
           └─15992 /usr/sbin/httpd -DFOREGROUND

Aug 05 17:14:31 thvtstrhl7 systemd[1]: Starting The Apache HTTP Server...
Aug 05 17:14:31 thvtstrhl7 systemd[1]: Started The Apache HTTP Server.

It can be done for any services as required. I hope this article helps you.

Systemd allows you to configure a service so that it automatically restarts in case it’s crashed.

Take a typical unit file that looks like this.

$ cat /etc/systemd/system/yourdaemon.service
[Unit]
Description=Your Daemon
After=network-online.target
Wants=network-online.target systemd-networkd-wait-online.service

[Service]
ExecStart=/path/to/daemon

[Install]
WantedBy=multi-user.target

Most unit files are longer, but this gives you the gist of it. In the above example, if your daemon would crash or be killed, systemd would leave it alone.

You can however let systemd auto-restart it in case it fails or is accidentally killed. To do so, you can add the Restart option to the [Service] stanza.

$ cat /etc/systemd/system/yourdaemon.service
[Unit]
Description=Your Daemon
After=network-online.target
Wants=network-online.target systemd-networkd-wait-online.service

StartLimitIntervalSec=500
StartLimitBurst=5

[Service]
Restart=on-failure
RestartSec=5s

ExecStart=/path/to/daemon

[Install]
WantedBy=multi-user.target

The above will react to anything that stops your daemon: a code exception, someone that does kill -9 <pid>, … as soon as your daemon stops, systemd will restart it in 5 seconds.

In this example, there are also StartLimitIntervalSec and StartLimitBurst directives in the [Unit] section. This prevents a failing service from being restarted every 5 seconds. This will give it 5 attempts, if it still fails, systemd will stop trying to start the service.

(Note: if you change your systemd unit file, make sure to run systemctl daemon-reload to reload the changes.)

If you ask for the status of your daemon after it’s been killed, systemd will show activating (auto-restart).

$ systemctl status yourdaemon
● yourdaemon.service - Your Daemon
   Loaded: loaded (/etc/systemd/system/yourdaemon.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: signal) since Mon 2020-01-13 09:07:41 UTC; 4s ago
  Process: 27165 ExecStart=/path/to/daemon (code=killed)
  Main PID: 27165 (code=killed, signal=KILL)

Give it a few seconds, and you’ll see the daemon was automatically restarted by systemd.

$ systemctl status yourdaemon
● yourdaemon.service - Your Daemon
   Loaded: loaded (/etc/systemd/system/yourdaemon.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2020-01-13 09:07:46 UTC; 6min ago

Pretty useful if you have a buggy service that’s safe to just restart on failure!

Достаточно часто бывает необходимость не позволять сервисам падать «наглухо», а рестартовать их в случае аварийного завершения. Systemd позволяет это сделать достаточно просто.

Рассмотрим в качестве примера древний сервис php5-fpm:

systemctl status php5-fpm.service
● php5-fpm.service - The PHP FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php5-fpm.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-06-30 10:14:55 MSK; 12h ago
  Process: 9349 ExecStartPre=/usr/lib/php5/php5-fpm-checkconf (code=exited, status=0/SUCCESS)
 Main PID: 9354 (php5-fpm)
   Status: "Processes active: 0, idle: 5, Requests: 499, slow: 0, Traffic: 0req/sec"
    Tasks: 6 (limit: 4700)
   Memory: 857.9M
   CGroup: /system.slice/php5-fpm.service
           ├─ 9354 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
           ├─ 9357 php-fpm: pool web19
           ├─ 9358 php-fpm: pool web19
           ├─ 9359 php-fpm: pool www
           ├─ 9360 php-fpm: pool www
           └─20671 php-fpm: pool www

Открываем на редактирование файл /lib/systemd/system/php5-fpm.service и видим обычное содержимое:

[Unit]
Description=The PHP FastCGI Process Manager
After=network.target

[Service] 
Type=notify
PIDFile=/var/run/php5-fpm.pid
ExecStartPre=/usr/lib/php5/php5-fpm-checkconf
ExecStart=/usr/sbin/php5-fpm --nodaemonize --fpm-config /etc/php5/fpm/php-fpm.conf
ExecReload=/bin/kill -USR2 $MAINPID

[Install]
WantedBy=multi-user.target

В случае некорректного завершения его работы, он не перезапустится автоматически и сайты, которые он ещё обслуживает, будут недоступны. Чтобы сервис перезапустился автоматически, нужно в секцию Unit добавить следующий строки:

StartLimitIntervalSec=500
StartLimitBurst=5

А в секцию Service добавить:

Restart=on-failure
RestartSec=5s

После добавления нужно заставить systemd перечитать конфиги:

systemctl daemon-reload

И теперь, если сервис вдруг остановится по незапланированным причинам, в течение 5 секунд он будет перезапущен. Попыток рестарта сервиса будет 5 в течение 500 секунд и если все эти попытки закончатся неудачей, дальнейших попыток перезапуска не будет. Этого времени должно хватить сисадмину, чтобы среагировать на проблему вручную. 🙂

На чтение 6 мин Опубликовано 07.08.2019

Существует множество причин сбоя / падения процесса в системе Linux, которые вы можете исследовать и устранить, но это может занять некоторое время.

Но одна вещь, которую вы можете сделать немедленно, чтобы перевести службу в оперативный режим, – это автоматический запуск, когда служба выходит из строя, что в конечном итоге сокращает время простоя и улучшает доступность.

Убедитесь, что ваш сервис всегда будет доступен для пользователей.

Это очень легко автоматизировать в системах systemd, поскольку в systemd есть опции, позволяющие это сделать.

Это также можно сделать с помощью bash-скрипта.

Что такое systemd?

Systemd – это новая система инициализации и менеджер системы, которая была внедрена / адаптирована во все основные дистрибутивы Linux поверх традиционных систем инициализации SysV.

systemd совместим со скриптами инициализации SysV и LSB.

Он может работать в качестве замены для системы sysvinit.

systemd – это первый процесс, запускаемый ядром и содержащий PID 1.

Это родительский процесс для всего, и Fedora 15 является первым дистрибутивом, который был адаптирован systemd вместо upstart.

systemctl – это утилита командной строки и основной инструмент для управления демонами / службами systemd, а именно (запуск, перезапуск, остановка, включение, отключение, перезагрузка и состояние).

systemd использует файлы .service вместо скриптов bash (используемых SysV init). systemd сортирует все демоны в свои собственные cgroups Linux, и вы можете увидеть иерархию системы, изучив файл /cgroup/systemd.

Сервисный файл systemd состоит из трех основных частей, и нам нужно добавить ниже обязательные параметры в разделе [Serivece]

[Unit]
...

[Service]
Restart=on-failure
RestartSec=5s
...

[Install]
...
  • Restart: определяет, будет ли служба перезапущена, когда процесс службы завершается, завершается или по истечении времени ожидания.
  • on-failure: если установлено значение on-failuire, служба будет перезапущена, когда процесс завершится с ненулевым кодом выхода, завершится с помощью сигнала, когда истечет время ожидания операции (например, перезагрузки службы), и когда настроен тайм-аут сторожевого таймера.
  • EstRestartSec: настраивает время ожидания перед перезапуском службы. Принимает значение без единиц измерения в секундах или значение промежутка времени, например «5min 20s». По умолчанию 100 ms.
  • S5s: он будет ждать 5 секунд, а затем запустить службу.

Как добавить параметр службы автоматического запуска в systemd System?

Нет ничего сложного в том, чтобы добавить эти параметры.

Для этого откройте соответствующий файл службы и добавьте следующие параметры.

Чтобы объяснить все это на примере, мы собираемся протестировать сервис httpd.

Давайте посмотрим его.

# vi /etc/systemd/system/multi-user.target.wants/httpd.service

[Unit]
Description=Apache Web Server
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=simple
ExecStart=/usr/bin/httpd -k start -DFOREGROUND
ExecStop=/usr/bin/httpd -k graceful-stop
ExecReload=/usr/bin/httpd -k graceful
PrivateTmp=true
LimitNOFILE=infinity
KillMode=mixed
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

Вам необходимо перезагрузить службу демона после внесения изменений.

Вы можете увидеть то же самое, запустив команду «systemctl status [httpd]», как показано ниже.

Кроме того, веб-сервер Apache httpd был запущен 27 минут назад.

# systemctl status httpd

● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2019-08-05 16:45:24 CDT; 27min ago
     Docs: man:httpd(8)
           man:apachectl(8)
  Process: 14420 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE)
Main PID: 14424 (httpd)
   Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"
   CGroup: /system.slice/httpd.service
           ├─14424 /usr/sbin/httpd -DFOREGROUND
           ├─14425 /usr/sbin/httpd -DFOREGROUND
           ├─14426 /usr/sbin/httpd -DFOREGROUND
           ├─14427 /usr/sbin/httpd -DFOREGROUND
           ├─14428 /usr/sbin/httpd -DFOREGROUND
           └─14429 /usr/sbin/httpd -DFOREGROUND

Aug 05 16:45:23 thvtstrhl7 systemd[1]: Stopped The Apache HTTP Server.
Aug 05 16:45:23 thvtstrhl7 systemd[1]: Starting The Apache HTTP Server...
Aug 05 16:45:24 thvtstrhl7 systemd[1]: Started The Apache HTTP Server.
Warning: httpd.service changed on disk. Run 'systemctl daemon-reload' to reload units.




Просто перезапустите службу

# systemctl daemon-reload

Можно проверить, выполнив следующую команду еще раз.

# systemctl status httpd

● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2019-08-05 16:45:24 CDT; 27min ago
     Docs: man:httpd(8)
           man:apachectl(8)
Main PID: 14424 (httpd)
   Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"
   CGroup: /system.slice/httpd.service
           ├─14424 /usr/sbin/httpd -DFOREGROUND
           ├─14425 /usr/sbin/httpd -DFOREGROUND
           ├─14426 /usr/sbin/httpd -DFOREGROUND
           ├─14427 /usr/sbin/httpd -DFOREGROUND
           ├─14428 /usr/sbin/httpd -DFOREGROUND
           └─14429 /usr/sbin/httpd -DFOREGROUND

Aug 05 16:45:23 thvtstrhl7 systemd[1]: Stopped The Apache HTTP Server.
Aug 05 16:45:23 thvtstrhl7 systemd[1]: Starting The Apache HTTP Server...
Aug 05 16:45:24 thvtstrhl7 systemd[1]: Started The Apache HTTP Server.

Чтобы поэкспериментировать с этим, используйте команду pidof, чтобы узнать PID процесса.

# pidof httpd

14429 14428 14427 14426 14425 14424

Как только вы получите информацию о PID, просто убейте их всех вместе, используя следующую команду.

# kill -9 14429 14428 14427 14426 14425 14424

После того, как вы убили PIDы httpd, просто выполните следующую команду, чтобы увидеть статус.

Система показывает, что служба выполняет автозапуск.

# systemctl status httpd

● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: activating (auto-restart) (Result: exit-code) since Mon 2019-08-05 17:14:26 CDT; 2s ago
     Docs: man:httpd(8)
           man:apachectl(8)
  Process: 15978 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE)
  Process: 14424 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=killed, signal=KILL)
Main PID: 14424 (code=killed, signal=KILL)
   Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"

Aug 05 17:14:26 thvtstrhl7 systemd[1]: httpd.service: control process exited, code=exited status=1
Aug 05 17:14:26 thvtstrhl7 systemd[1]: Unit httpd.service entered failed state.
Aug 05 17:14:26 thvtstrhl7 systemd[1]: httpd.service failed.

Позвольте мне выполнить приведенную выше команду еще раз и посмотреть, как выглядят результаты.

Да, круто, все работает, как ожидалось.

Служба была запущена 564 миллисекунды назад.

# systemctl status httpd

● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2019-08-05 17:14:31 CDT; 564ms ago
     Docs: man:httpd(8)
           man:apachectl(8)
  Process: 15978 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE)
Main PID: 15987 (httpd)
   Status: "Processing requests..."
   CGroup: /system.slice/httpd.service
           ├─15987 /usr/sbin/httpd -DFOREGROUND
           ├─15988 /usr/sbin/httpd -DFOREGROUND
           ├─15989 /usr/sbin/httpd -DFOREGROUND
           ├─15990 /usr/sbin/httpd -DFOREGROUND
           ├─15991 /usr/sbin/httpd -DFOREGROUND
           └─15992 /usr/sbin/httpd -DFOREGROUND

Aug 05 17:14:31 thvtstrhl7 systemd[1]: Starting The Apache HTTP Server...
Aug 05 17:14:31 thvtstrhl7 systemd[1]: Started The Apache HTTP Server.

Пожалуйста, не спамьте и никого не оскорбляйте.

Это поле для комментариев, а не спамбокс.

Рекламные ссылки не индексируются!

I have written this service that runs TCP server using node.js to take data from micro controller to mysql server.

root@DietPi:~# sudo cat /lib/systemd/system/mysqlwifi.service 
 [Unit]
 Description=MySQL exampledb update
 After=multi-user.target
 After=network-online.target
 Wants=network-online.target

 [Service]
 Type=idle
 ExecStart=/usr/bin/node /home/dietpi/node_server/mysqlwifi.js > /home/dietpi/node_server/mysqlwifi.log 2>&1

 [Install]
 WantedBy=multi-user.target
root@DietPi:~#

Since this service is critical to push data to mysql i want it to automatically restart on failure. I also want to know how can I send an email on each failure or when service comes back live.

asked Oct 27, 2019 at 7:21

Ciasto piekarz's user avatar

Ciasto piekarzCiasto piekarz

7,81117 gold badges96 silver badges193 bronze badges

[Service]
Restart=on-failure

Setting Restart=on-failure to your unit configuration should do it, but check Restart documentation for more options.
To send an email you could use an ExecStartPost= clause with a mailx call.

Victor Häggqvist's user avatar

answered Oct 29, 2019 at 19:27

Sebastián's user avatar

1

We were recently faced with a service that crashed occasionally on one of our Linux
servers. We had to find a way to make it recover automatically, ideally using tools
that were already present on the server.

The landscape of process-management in Linux is somewhat complex and is in a state of
flux, with different tools vying to replace the venerable SysV-style
init that sysadmins have relied on for decades.
Luckily, it looks like the highly-capable systemd is becoming the standard, and we’ll
hopefully have another long stable period soon.

In the meantime, we needed to get our service running reliably. In our case, the
delayed_job service that supported one of our Rails apps was stopping occasionally. The
service was controlled by a SysV-style init script in /etc/init.d, and it was started
automatically when the system started up. Unfortunately, SysV-style init doesn’t include
monitoring or auto-restart capability*.

* You can actually used the respawn feature in the /etc/inittab file, but that
looked too scary to us!

Now that systemd is becoming a standard (present on Ubuntu 14.10+, RedHat, 7+, CentOS
7+, and Fedora 15+), we wanted to learn how to use it. systemd is controlled by
.service files in a variety of locations. However, we wanted to avoid rewriting the
existing startup script. Our research revealed the following:

  • systemd is compatible with legacy /etc/init.d scripts in this manner: when systemd
    loads service definitions, the
    systemd-sysv-generator
    generates .service files on the fly from the scripts in /etc/init.d.
  • You can add configuration to a service by adding “drop-in” files to a correctly-named
    folder in /etc/systemd/system/.

So, we simply had to add a file like this at /etc/systemd/system/delayed_job.service.d/restart.conf:


[Service]
Type=forking
PIDFile=/srv/www/sites/rails_app/current/tmp/pids/delayed_job.pid
RemainAfterExit=no
Restart=on-failure
RestartSec=5s

This configuration will vary for different services. You’ll have to read the
systemd.service
docs to figure out
the specifics. In particular, you should read the docs for the Type, Restart,
GuessMainPID, PIDFile, and RemainAfterExit options.

Then, after reloading our service definitions with systemd daemon-reload, we can see
that systemd knew what it needed to know about our service.


$ sudo systemctl status delayed_job
● delayed_job.service - LSB: Manage delayed jobs for application rails_app
   Loaded: loaded (/etc/init.d/delayed_job; bad; vendor preset: enabled)
  Drop-In: /etc/systemd/system/delayed_job.service.d
           └─restart.conf
   Active: active (running) since Mon 2017-10-23 15:33:25 CDT; 12min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 6359 ExecStop=/etc/init.d/delayed_job stop (code=exited, status=0/SUCCESS)
  Process: 6389 ExecStart=/etc/init.d/delayed_job start (code=exited, status=0/SUCCESS)
 Main PID: 6412 (bundle)
   CGroup: /system.slice/delayed_job.service
           ‣ 6412 delayed_job   

Notice the “Drop-In” section, which tells us that systemd knows about the new config
file we added, and the Main PID line, which indicates that systemd knows which process
to monitor.

We can test this config by force-killing the service in question: sudo kill -9 6412.
Running system status delayed_job immediately will show something like Active:
deactivating (stop) (Result: signal)
. Within 5 seconds (per the config), It should return
to saying Active: active (running).

If you’re using an older distro, or one that doesn’t have systemd for any reason, check
out Digital Ocean’s exhaustive guide to automatic service recovery.

Понравилась статья? Поделить с друзьями:
  • Systemair коды ошибок внутреннего блока кондиционера
  • Systemair vrv коды ошибок
  • System ошибка при загрузке куста
  • System windows forms ошибка
  • System thread exception not handled win 10 ошибка