Сервис перезапускался при ошибке on failure

Иногда сервисы ни с того ни с сего падают и приходиться их вручную восстанавливать. Если для пользователя домашнего компьютера это не критично, потому что если сервис падает во время разработки, то это даже хорошо, можно сразу увидеть что есть проблема. Но на серверах и 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

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

Источник

Решил вопрос: в итоге два юнита и bash лупер.
Первый юнит поднимает сервер от непривилегированного юзера:

[Unit]
Description=HTTrack web-server for 'vps'
After=network.target

[Service]
User=vps
Group=vps
Type=simple
ExecStart=/usr/lib/httrack/htsserver /usr/share/httrack/ --path /home/vps/httrack --language 8 --port 2340

[Install]
WantedBy=multi-user.target

Второй – контролёр первого:

[Unit]
Description=HTTrack bicycle
After=network.target

[Service]
Type=simple
ExecStart=/etc/httrack.sh
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

И луп (добивает, пока паучок не запустится с сокетом):

#!/bin/sh

while true
do
    if [ -z "$(netstat -tulpn | grep 2340)" ]
    then
        systemctl restart httrack-trans.service
    fi
    sleep 10
done

Не нравится, что на три файла разбросал. Триппер, конечно, но работает. Думаю, если бы HTTrack при траблах с соккетом завершался с каким-нибудь ненулевым кодом, то можно было реализовать ту же логику одним systemd.

Жалко, проект уже умирает. Так и не придумал, как по человечески закрыть вот эту дырку:

strace -f -e open ls 2>&1 | grep ^open
open("/usr/share/httrack/html/ping", O_RDONLY) = -1 ENOENT (No such file or directory)

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

Благодарю за обсуждение и советы.

rmu ★★

(09.11.19 18:05:56 MSK)

  • Показать ответ
  • Ссылка
Источник

На чтение 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.

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

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

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

Источник

Достаточно часто бывает необходимость не позволять сервисам падать «наглухо», а рестартовать их в случае аварийного завершения. 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 секунд и если все эти попытки закончатся неудачей, дальнейших попыток перезапуска не будет. Этого времени должно хватить сисадмину, чтобы среагировать на проблему вручную. 🙂

Источник

systemd version the issue has been seen with

253.1 / 252.6

Used distribution

Arch / Debian 12

Linux kernel version used

6.2.7-zen1-1-zen / 6.1.0-6-amd64

CPU architectures issue was seen on

x86_64

Component

systemd

Expected behaviour you didn’t see

OnSuccess dependencies are triggered after the unit completed successfully.

Unexpected behaviour you saw

OnSuccess dependencies are also triggered while the unit is restarting, when Restart=on-failure is set.

Steps to reproduce the problem

Use two dummy units

# /etc/systemd/system/myservice.service
[Unit]
OnSuccess=mysuccess.service
StartLimitBurst=2
StartLimitIntervalSec=1h


[Service]
Type=oneshot
ExecStart=/usr/bin/false
Restart=on-failure

# /etc/systemd/system/mysuccess.service
[Service]
Type=oneshot
ExecStart=/usr/bin/true

When starting myservice.service, this will also trigger mysuccess.service multiple times.

Additional program output to the terminal or log subsystem illustrating the issue

Mar 20 15:49:21 periculum systemd[1]: Starting myservice.service...
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Child 4446 belongs to myservice.service.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Main process exited, code=exited, status=1/FAILURE
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Failed with result 'exit-code'.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Service will restart (restart setting)
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Changed start -> failed
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Job 3357 myservice.service/start finished, result=failed
Mar 20 15:49:21 periculum systemd[1]: Failed to start myservice.service.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Unit entered failed state.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Consumed 1ms CPU time.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Changed failed -> auto-restart
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Service RestartSec=100ms expired, scheduling restart.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Trying to enqueue job myservice.service/restart/replace
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Installed new job myservice.service/restart as 3481
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Enqueued job myservice.service/restart as 3481
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Scheduled restart job, restart counter is at 1.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Changed auto-restart -> dead
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Job 3481 myservice.service/restart finished, result=done
Mar 20 15:49:21 periculum systemd[1]: Stopped myservice.service.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Converting job myservice.service/restart -> myservice.service/start
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Consumed 1ms CPU time.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Triggering OnSuccess= dependencies.
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Trying to enqueue job mysuccess.service/start/fail
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Installed new job mysuccess.service/start as 3605
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Enqueued job mysuccess.service/start as 3605
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Triggering OnSuccess= dependencies done (1 job).
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Will spawn child (service_enter_start): /usr/bin/false
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Passing 0 fds to service
Mar 20 15:49:21 periculum systemd[1]: myservice.service: About to execute /usr/bin/false
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Forked /usr/bin/false as 4448
Mar 20 15:49:21 periculum (false)[4448]: myservice.service: Executing: /usr/bin/false
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Changed dead -> start
Mar 20 15:49:21 periculum systemd[1]: Starting myservice.service...
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Will spawn child (service_enter_start): /usr/bin/true
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Passing 0 fds to service
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: About to execute /usr/bin/true
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Forked /usr/bin/true as 4449
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Changed dead -> start
Mar 20 15:49:21 periculum systemd[1]: Starting mysuccess.service...
Mar 20 15:49:21 periculum (true)[4449]: mysuccess.service: Executing: /usr/bin/true
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Child 4448 belongs to myservice.service.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Main process exited, code=exited, status=1/FAILURE
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Failed with result 'exit-code'.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Service will restart (restart setting)
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Changed start -> failed
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Job 3481 myservice.service/start finished, result=failed
Mar 20 15:49:21 periculum systemd[1]: Failed to start myservice.service.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Unit entered failed state.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Consumed 1ms CPU time.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Changed failed -> auto-restart
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Child 4449 belongs to mysuccess.service.
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Main process exited, code=exited, status=0/SUCCESS (success)
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Deactivated successfully.
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Service will not restart (restart setting)
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Changed start -> dead
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Job 3605 mysuccess.service/start finished, result=done
Mar 20 15:49:21 periculum systemd[1]: Finished mysuccess.service.
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Consumed 1ms CPU time.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Control group is empty.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Service RestartSec=100ms expired, scheduling restart.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Trying to enqueue job myservice.service/restart/replace
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Installed new job myservice.service/restart as 3729
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Enqueued job myservice.service/restart as 3729
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Scheduled restart job, restart counter is at 2.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Changed auto-restart -> dead
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Job 3729 myservice.service/restart finished, result=done
Mar 20 15:49:21 periculum systemd[1]: Stopped myservice.service.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Converting job myservice.service/restart -> myservice.service/start
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Consumed 1ms CPU time.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Triggering OnSuccess= dependencies.
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Trying to enqueue job mysuccess.service/start/fail
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Installed new job mysuccess.service/start as 3853
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Enqueued job mysuccess.service/start as 3853
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Triggering OnSuccess= dependencies done (1 job).
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Start request repeated too quickly.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Failed with result 'exit-code'.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Service restart not allowed.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Changed dead -> failed
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Job 3729 myservice.service/start finished, result=failed
Mar 20 15:49:21 periculum systemd[1]: Failed to start myservice.service.
Mar 20 15:49:21 periculum systemd[1]: myservice.service: Unit entered failed state.
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Will spawn child (service_enter_start): /usr/bin/true
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Passing 0 fds to service
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: About to execute /usr/bin/true
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Forked /usr/bin/true as 4450
Mar 20 15:49:21 periculum (true)[4450]: mysuccess.service: Executing: /usr/bin/true
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Changed dead -> start
Mar 20 15:49:21 periculum systemd[1]: Starting mysuccess.service...
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Child 4450 belongs to mysuccess.service.
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Main process exited, code=exited, status=0/SUCCESS (success)
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Deactivated successfully.
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Service will not restart (restart setting)
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Changed start -> dead
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Job 3853 mysuccess.service/start finished, result=done
Mar 20 15:49:21 periculum systemd[1]: Finished mysuccess.service.
Mar 20 15:49:21 periculum systemd[1]: mysuccess.service: Consumed 2ms CPU time.
Источник

Возможно, вам также будет интересно:

  • Сервис недоступен код ошибки 101 теле 2
  • Сервис не ответил вовремя внутренняя ошибка сервера возможно сервер неверно сконфигурирован
  • Сервис не может быть использован на этой sim карте код ошибки 34хх
  • Сервис не может быть использован на этой sim карте код ошибки 34 xx что это
  • Сервис не может быть использован на этой sim карте код ошибки 01xx

    • Понравилась статья? Поделить с друзьями:
    0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии