Linux автоматический перезапуск службы

Как выполнить автоматический перезапуск сервиса Linux

Часто происходит спонтанное падение сервиса. Пользователю приходится заниматься их ручным восстановлением. Проблемы как таковой нет, если это происходит на домашнем компьютере. Даже больше – это хорошо, ведь появляется реальная возможность определить состояние сервиса, выявить неисправности и устранить их. Но совсем другая ситуация, когда дело касается серверов и VPS сервисов, которые должны работать постоянно для обеспечения доступа к веб-сайту или приложению. В этой статье рассмотрим способ настройки автоматического перезапуска сервиса Linux несколькими способами: с помощью скрипта мониторинга периодически запускаемого через cron и в systemd.

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

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

$ sudo systemctl edit apache2

[Service]

Restart=on-failure

RestartSec=5s

Здесь RestartSec указывает, сколько ждать перед перезапуском сервиса. Когда завершите работу, сохраните изменения и выполните команду 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

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

Источник

How to automatically restart Linux services with Systemd

Getting your Linux deployments working reliably is of paramount concern for production applications. One way to guarantee that a service is always available is to ensure that it is automatically restarted in the event of a crash, and Systemd provides the necessary tools to make it happen.

A useful feature that is often needed for long-running processes such as web servers is the ability to automatically restart the process in the event of a crash in order to minimise downtime. If your service is being managed by Systemd, you can use the /etc/systemd/system/daemon.service

[Unit] Description=Your Daemon Name  [Service] ExecStart=/path/to/executable Restart=on-failure RestartSec=1s  [Install] WantedBy=multi-user.target

In the above service configuration file, Restart is set to on-failure so that the service is restarted if the service exits with a non-zero exit code, or if terminated using a signal (such as using the kill command for example). The RestartSec option configures the amount of time to wait before restarting the service. Here, it’s set to one second to override the default value of 100ms.

After updating your Systemd unit file, ensure to run the command below to ensure your changes take effect:

$ sudo systemctl daemon-reload

Two other useful options that you should be aware of are StartLimitIntervalSec and StartLimitBurst . They are both useful for configuring when Systemd should stop trying to restart a service. The former specifies a time interval in seconds, while the latter specifies the maximum amount of times that is allowed for the service to be restarted within the specified interval.

[Unit] Description=Your Daemon Name StartLimitIntervalSec=300 StartLimitBurst=5  [Service] ExecStart=/path/to/executable Restart=on-failure RestartSec=1s  [Install] WantedBy=multi-user.target

According to the configuration above, the service is not allowed to restart more than five times within a 300 second interval. If the service crashes more than five times, it will not be permitted to start anymore.

After reloading the systemd manager configuration ( sudo systemctl daemon-reload ), kill your running service and confirm that it is automatically restarted after the time specified by RestartSec has elapsed.

About the Author

Ayo is a Software Developer by trade. He enjoys writing about diverse technologies in web development, mainly in Go and JavaScript/TypeScript.
Learn more.

Источник

Configure a Systemd Service to Restart Periodically

The Kubernetes ecosystem is huge and quite complex, so it’s easy to forget about costs when trying out all of the exciting tools.

To avoid overspending on your Kubernetes cluster, definitely have a look at the free K8s cost monitoring tool from the automation platform CAST AI. You can view your costs in real time, allocate them, calculate burn rates for projects, spot anomalies or spikes, and get insightful reports you can share with your team.

Connect your cluster and start monitoring your K8s costs right away:

1. Introduction

Sometimes, we need to restart systemd services to resolve operational errors. We can automate this using various methods in Linux. In this tutorial, we’ll look at three ways in which we can restart a systemd service periodically.

2. Using a Oneshot Service

Oneshot services are systemd services that perform a specific task and terminate upon completion of that task. In other words, the process is short-lived. We can periodically start a systemd service using a timer and a oneshot service. We’ll use the timer service to trigger the oneshot service. Subsequently, the oneshot service will be responsible for restarting our systemd service. We create all systemd service unit files in the /etc/systemd/system directory. We create three systemd unit files called my-service.service, oneshot.service, and my-service.timer. Let’s define a service called my-service.service, which will perform a specific task:

$ sudo vi my-service.service [Unit] Description=Simple service [Service] Type=simple ExecStart=/usr/bin/logger hello [Install] WantedBy=multi-user.target

This service will make a simple entry into the system log. In our case, we are logging the message “hello“. Therefore, we should see the “hello” output in our logs once the service runs. Subsequently, let’s create the oneshot.service file:

$ sudo vi oneshot.service [Unit] Description=One shot service [Service] Type=oneshot ExecStart=/usr/bin/systemctl restart my-service.service [Install] WantedBy=multi-user.target

The oneshot.service file will restart my-service.service. Lastly, we set up the systemd timer:

$ sudo vi my-service.timer [Unit] Description=Run oneshot service periodically [Timer] Unit=oneshot.service OnCalendar=Mon..Fri 10:30 [Install] WantedBy=timers.target

The oneshot.service file will be triggered by the systemd timer we’ve created. In this example, the systemd service my-service will restart at 10:30 a.m. on weekdays. Furthermore, we start the timer just as we’d start any other systemd service:

$ systemctl enable --now my-service.timer

We can see when the timer has run and when it is going to run by listing the systemd timers:

$ systemctl list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Fri 2021-12-24 09:39:42 SAST 3min 13s left Fri 2021-12-24 08:36:22 SAST 1h 0min ago dnf-makecache.timer dnf-makecache.service Fri 2021-12-24 10:30:00 SAST 53min left Fri 2021-12-24 09:22:03 SAST 14min ago my-service.timer oneshot.service

After checking the system logs, we see that our service did run:

$ journalctl --since "5 minutes ago" Dec 24 10:30:03 localhost.localdomain systemd[1]: Started Simple service. Dec 24 10:30:03 localhost.localdomain systemd[1]: oneshot.service: Succeeded. Dec 24 10:30:03 localhost.localdomain systemd[1]: Started One shot service. Dec 24 10:30:03 localhost.localdomain root[4385]: hello Dec 24 10:30:03 localhost.localdomain systemd[1]: my-service.service: Succeeded.

3. Using the RuntimeMaxSec and the Restart Options

Alternatively, we can use the RuntimeMaxSec option to terminate a systemd service after running for a certain amount of time. Also, we set the Restart descriptor to always. This option makes sure that the service is always restarted. This method doesn’t work on oneshot services. This is because oneshot services always terminate upon the completion of a task. Thus, using the my-service.service unit file won’t work in this case. Let’s create a simple systemd service and name it my-service1.service:

$ sudo vi my-service1.service [Unit] Description=Simple service [Service] ExecStart=/usr/bin/python3 /root/app.py RuntimeMaxSec=180s Restart=always [Install] WantedBy=multi-user.target

This service will execute a basic python program that runs indefinitely. Moreover, this service will terminate after 180 seconds and restart again:

Dec 24 18:50:57 localhost systemd[1]: Started Simple service. Dec 24 18:53:57 localhost systemd[1]: my-service1.service: Service reached runtime time limit. Stopping. Dec 24 18:53:57 localhost systemd[1]: my-service1.service: Failed with result 'timeout'. Dec 24 18:53:57 localhost systemd[1]: my-service1.service: Service RestartSec=100ms expired, scheduling restart. Dec 24 18:53:57 localhost systemd[1]: my-service1.service: Scheduled restart job, restart counter is at 1. Dec 24 18:53:57 localhost systemd[1]: Stopped Simple service. Dec 24 18:53:57 localhost systemd[1]: Started Simple service.

4. Using a Cronjob

Alternatively, we can specify the command we’d like to run in a crontab instead of a service file. Let’s edit our crontab:

$ crontab -e 30 10 * * 1-5 /usr/bin/systemctl restart my-service.service

Here, our entry specifies that we want to restart my-service.service at 10:30 a.m. every weekday. Furthermore, if the service is disabled, it’ll be started again.

5. Conclusion

In this article, we’ve explored different techniques that allow us to gracefully restart simple and oneshot systemd services.

Источник