StartLimitIntervalSec и StartLimitBurst в Systemd никогда не работают

Я пытался ограничить количество перезапуска службы (в контейнере). Версия ОС - centos-release-7-5, служебный файл примерно такой же, как показано ниже (некоторые параметры удалены для удобства чтения). Это должно быть довольно просто, как указывалось в некоторых других публикациях (ограничение перезапуска после сбоя сервера, ограничение перезапуска после переполнения стека 2). Все же StartLimitBurst и StartLimitIntervalSec никогда не работают для меня.

Я проверил несколько способов: (1) Я проверяю PID службы, убиваю службу с помощью команды «kill -9 ****» несколько раз. Сервис всегда перезапускается после 20 лет! (2) Я также попытался испортить служебный файл, чтобы контейнер никогда не работал. Тем не менее, это не работает, сервисный файл просто продолжает перезапускаться.

Есть идеи?

[Unit]
Description=Hello Fluentd
After=docker.service
Requires=docker.service
StartLimitBurst=2
StartLimitIntervalSec=150s

[Service]
EnvironmentFile=/etc/environment
ExecStartPre=-/usr/bin/docker stop "fluentd"
ExecStartPre=-/usr/bin/docker rm -f "fluentd"
ExecStart=/usr/bin/docker run fluentd
ExecStop=/usr/bin/docker stop "fluentd"
Restart=always
RestartSec=20s
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target

linux systemd

— batilei
источник

Это более важно, чем тот, кто забыл набрать «Sec», как показывают ответы. Я не думаю, что полезно закрывать такой вопрос, который задавался с таким количеством деталей, которые мы хотим.

— sourcejedi

Ответы:

StartLimitIntervalSec=был добавлен как часть systemd v230. В systemd v229 и ниже вы можете использовать только StartLimitInterval=. Вам также нужно будет поставить StartLimitInterval=и StartLimitBurst=в [Service]разделе - не в [Unit]разделе.

Чтобы проверить версию systemd в CentOS, запустите rpm -q systemd.

Если вы когда-нибудь обновитесь до systemd v230 или выше, старые имена в этом [Service]разделе будут продолжать работать.

Источник: https://lists.freedesktop.org/archives/systemd-devel/2017-July/039255.html

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

Можно вручную проверить файл модуля на наличие неизвестных директив. По крайней мере, похоже, что работает на недавнем systemd:

$ systemd-analyze verify foo.service
/etc/systemd/system/foo.service:9: Unknown lvalue 'FancyNewOption' in section 'Service'

— sourcejedi
источник

Это интересно. Вы предлагаете поместить StartLimitBurstв раздел [Service], но в документации сказано, что это должно быть в разделе [Unit]. freedesktop.org/software/systemd/man/systemd.unit.html

StartLimitIntervalSec=interval, StartLimitBurst=burst Configure unit start rate limiting. Units which are started more than burst times within an interval time interval are not permitted to start any more.

— Ikrom

@Ikrom В systemd v229 и ниже

— sourcejedi

@sourcejedi Спасибо! Только что проверил systemd на моем centos 7, /usr/lib/systemd/systemd --versionи это был v219. Мне нужно позаботиться о версии systemd.

— Икром

+10 если бы мог. Я искал это решение несколько раз раньше (и, по-видимому, плохо гуглил). Также новым для меня является systemd-analyze. Спасибо!

— Джоттон

Кажется, это systemd-analyzeработает только для служебных файлов, которые уже установлены, но не для (скажем) локального файла, который вы пытаетесь записать, но еще не установили. (По крайней мере, это то, что, похоже, относится к v219 в моих попытках использовать его.) Если это правда, возможно, стоит упомянуть об этом в этом ответе.

— Муха

Я думаю, что нашел проблему. Все документы в Интернете предполагают, что все параметры находятся в файле UNIT (файл модуля systemd ), но все еще в моей системе (centos 7.5) они находятся в служебном файле. Кроме того, имя «StartLimitInterval», а не «StartLimitIntervalSec».

— batilei
источник