Есть ли способ узнать, когда системный таймер будет работать дальше?


19

Я тестирую системный таймер и пытаюсь изменить его тайм-аут по умолчанию, но безуспешно. Мне интересно, есть ли способ попросить systemd сообщить нам, когда сервис будет запущен в следующий раз.

Обычный файл ( /lib/systemd/system/snapbackend.timer):

# Documentation available at:
# https://www.freedesktop.org/software/systemd/man/systemd.timer.html

[Unit]
Description=Run the snapbackend service once every 5 minutes.

[Timer]
# You must have an OnBootSec (or OnStartupSec) otherwise it does not auto-start
OnBootSec=5min
OnUnitActiveSec=5min
# The default accuracy is 1 minute. I'm not too sure that either way
# will affect us. I am thinking that since our computers will be
# permanently running, it probably won't be that inaccurate anyway.
# See also:
# http://stackoverflow.com/questions/39176514/is-it-correct-that-systemd-timer-accuracysec-parameter-make-the-ticks-slip
#AccuracySec=1

[Install]
WantedBy=timers.target

# vim: syntax=dosini

Файл переопределения ( /etc/systemd/system/snapbackend.timer.d/override.conf):

# This file was auto-generated by snapmanager.cgi
# Feel free to do additional modifications here as
# snapmanager.cgi will be aware of them as expected.
[Timer]
OnUnitActiveSec=30min

Я выполнил следующие команды, и таймер по-прежнему тикает каждые 5 минут. Может ли быть ошибка в systemd?

sudo systemctl stop snapbackend.timer
sudo systemctl daemon-reload
sudo systemctl start snapbackend.timer

Так что мне было интересно, как я могу узнать, когда таймер будет дальше? Потому что это сразу скажет мне, будет ли это через 5 минут. или 30 мин. но из этого systemctl status snapbackend.timerничего не сказано об этом. Просто интересно, есть ли команда, которая сообщит мне о задержке, используемой в настоящее время.

Для тех, кто заинтересован, есть сервисный файл тоже ( /lib/systemd/system/snapbackend.service), хотя я думаю, что это не должно влиять на тики таймера ...

# Documentation available at:
# https://www.freedesktop.org/software/systemd/man/systemd.service.html

[Unit]
Description=Snap! Websites snapbackend CRON daemon
After=snapbase.service snapcommunicator.service snapfirewall.service snaplock.service snapdbproxy.service

[Service]
# See also the snapbackend.timer file
Type=simple
WorkingDirectory=~
ProtectHome=true
NoNewPrivileges=true
ExecStart=/usr/bin/snapbackend
ExecStop=/usr/bin/snapstop --timeout 300 $MAINPID
User=snapwebsites
Group=snapwebsites
# No auto-restart, we use the timer to start once in a while
# We also want to make systemd think that exit(1) is fine
SuccessExitStatus=1
Nice=5
LimitNPROC=1000
# For developers and administrators to get console output
#StandardOutput=tty
#StandardError=tty
#TTYPath=/dev/console
# Enter a size to get a core dump in case of a crash
#LimitCORE=10G

[Install]
WantedBy=multi-user.target

# vim: syntax=dosini

1
Помогает ли вывод systemctl list-timers?
phg

Ах! В поисках этого я нашел эту страницу с решением: bbs.archlinux.org/viewtopic.php?id=214989 Я сейчас напишу ответ.
Алексис Уилке

Ответы:


25

Состояние текущих таймеров может быть показано с помощью systemctl list-timers:

$ systemctl list-timers --all
NEXT                         LEFT     LAST                         PASSED       UNIT                         ACTIVATES
Wed 2016-12-14 08:06:15 CET  21h left Tue 2016-12-13 08:06:15 CET  2h 18min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

1 timers listed.

7

Из комментария и ответа @phg я нашел страницу с ответом. Таймеры являются кумулятивными, и вам необходимо сначала сбросить их, в противном случае предыдущая запись останется. Это полезно для календарей, но работает одинаково со всеми таймерами.

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

# This file was auto-generated by snapmanager.cgi
# Feel free to do additional modifications here as
# snapmanager.cgi will be aware of them as expected.
[Timer]
OnUnitActiveSec=
OnUnitActiveSec=30min

1

Нет, там не появится способ увидеть точно, когда таймер будет работать дальше. systemdпредложения systemctl list-timersи systemctl status something.timer, но те, которые не показывают влияние AccuracySec=и, возможно, другие директивы, которые сдвигают время.

Если вы установите AccuracySec=1hна два сервера, они оба сообщат, что один и тот же таймер на обоих серверах будет срабатывать в одно и то же время, но на самом деле они могут запускаться с интервалом до часа! Если вам интересно узнать, могут ли столкнуться два рандомизированных таймера, похоже, нет способа проверить окончательное рассчитанное время выполнения, чтобы выяснить это.

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


Интересный момент про таймеры. Однако информация, которую мы получаем list-timers, уже достаточно хороша, чтобы понять, правильно ли вы используете таймеры или нет.
Алексис Вилке

1
Не в моем случае. Я хотел бы использовать одну и ту же конфигурацию на сдвоенных хостах, но используйте AccuracySec =, чтобы гарантировать, что оба не выполняют обслуживание одновременно. Я хотел бы видеть, когда таймеры действительно будут срабатывать на каждом хосте, но не могу.
Марк Стосберг

Ах. У меня похожие проблемы. Я бы использовал выбранный мастер (используя систему голосования), и мастер отправляет сообщение «выполнить обслуживание» на компьютер 1, как только компьютер 1 завершает работу, он сообщает своему новому статусу ведущему, который затем просит компьютер 2 выполнить его обслуживание, и т.д. Один из этих компьютеров, конечно, будет основным, но код, выполняющий цикл обслуживания, должен быть отделен от фактического обслуживания. Одна проблема, чтобы иметь в виду. Если ваш кластер будет расти совсем немного, помните, что на это требуется время, и оно может быть настолько длинным, что некоторые компьютеры не будут обновляться в течение длительного времени!
Алексис Вилке
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.