Вопрос или проблема
Команда systemctl list-timers покажет список таймеров на системе:
[root@arnie ~]# systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES >
Sun 2025-01-26 10:00:00 CET 1min 49s left Sun 2025-01-26 09:00:00 CET 58min ago [email protected] [email protected]
1 timers listed.
Pass --all to see loaded but inactive timers, too.
Таймер в приведённом случае потерпел неудачу:
[root@arnie ~]# systemctl status [email protected]
● [email protected] - Backup RouterOS Timer - balmoraldrive
Loaded: loaded (/usr/lib/systemd/system/[email protected]; disabled; preset: disabled)
Active: activating (auto-restart) (Result: exit-code) since Sun 2025-01-26 09:51:54 CET; 9min ago
TriggeredBy: ● [email protected]
Process: 433722 ExecStart=/bin/bash /usr/libexec/device-timer/backup-routeros start balmoraldrive (code=exited, status=255/EXCEPTION)
Main PID: 433722 (code=exited, status=255/EXCEPTION)
CPU: 420ms
Как я могу вывести список таймеров, которые потерпели неудачу при последнем запуске?
Очевидный ответ не работает:
[root@arnie ~]# systemctl list-timers --failed
NEXT LEFT LAST PASSED UNIT ACTIVATES
0 timers listed.
Pass --all to see loaded but inactive timers, too.
Таймер не потерпел неудачу. Единственная единица, которая потерпела неудачу, — это служба, запущенная этим таймером — и действительно, в вашем собственном сообщении вы запускали systemctl status на единице .service, чтобы увидеть отказ — в то время как сам таймер остаётся “активным”, что означает, что он всё еще запланирован.
Таким образом, единственный способ получить список — это посмотреть список служб:
systemctl --failed -t service
Если служба не переходит в состояние неудачи, следующее место для поиска — это системные журналы, где вы можете отфильтровать по конкретному сообщению:
# все сообщения уведомления/предупреждения/ошибки
journalctl -n 100 -t systemd -p notice
# "Не удалось запустить единицу"
journalctl -n 100 MESSAGE_ID=be02cf6855d2428ba40df7e9d022f03d
journalctl -n 100 JOB_RESULT=failed
# "Единица завершилась с этим результатом"
journalctl -n 100 MESSAGE_ID=d9b373ed55a64feb8242e02dbe79a49c
# "Основной процесс завершён"
journalctl -n 100 MESSAGE_ID=98e322203f7a4ed290d09fe03c09fe15
(Я получил фильтры, просмотрев journalctl -t systemd -o verbose. Вы можете объединить несколько фильтров, используя +, чтобы означать ‘ИЛИ’.)
Также: Избегайте размещения пользовательских единиц в /usr/lib; это территория менеджера пакетов.
Ответ или решение
Для получения списка таймеров systemd, которые завершились неудачно при последнем запуске, необходимо учитывать специфику работы с systemd, поскольку сама концепция "неудачного таймера" несколько отличается от неудачного выполнения связанной с ним службы. Это связано с тем, что таймеры systemd являются лишь расписанием для запуска определенных служб или команд, а реальная проверка успешности выполнения относится именно к этому связанному исполнению.
Теория
systemd предоставляет широкие возможности для автоматизации и управления системными сервисами и процессами. В частности, таймеры в systemd служат инструментом для запуска заранее определенных заданий (чаще всего это unit-файлы с расширением .service) в заданное время или через регулярные интервалы. Важно отметить, что сам таймер считается активным, пока он может запускать связанные с ним задачи. Таймер не "безуспешен" до тех пор, пока запланированное событие может быть исполнено, независимо от результата выполнения этой запланированной задачи. Следовательно, если возникает неудача, она происходит на уровне службы, а не таймера.
Пример
Представим, что вы настроили таймер, который запускает резервное копирование один раз в день. Пусть это будет файл backup-routeros.service, который вызывается таймером backup-routeros.timer. Если в процессе выполнения резервного копирования произошла ошибка, например, из-за отсутствия дискового пространства, это будет ошибка службы, а не таймера. Таймер всё ещё может попытаться запустить команду резервного копирования на следующий день, и он останется в активированном состоянии.
Для выявления таких случаев, когда служба завершилась с ошибкой при последнем запуске, вам необходимо сначала получить список всех "неудачных" служб, а не таймеров:
systemctl --failed -t serviceЭта команда предоставит список всех служб, которые завершились с ошибкой. Однако важный аспект в том, что не все службы остаются в состоянии "неудачи". Некоторые могут попытаться перезапустить или просто завершиться. Поэтому возможно понадобиться перепроверять системные журналы для нахождения таких событий.
Применение
Чтобы максимально эффективно управлять такими ситуациями, рассмотрите использование системного журнала journalctl для получения более детальной информации о неудачах в работе служб:
-
Получение всех сообщений о неудачных запусках:
journalctl -n 100 -t systemd -p notice -
Фильтрация сообщений о неудачных запусках службы:
journalctl -n 100 MESSAGE_ID=be02cf6855d2428ba40df7e9d022f03d journalctl -n 100 JOB_RESULT=failed -
Поиск причин выхода основного процесса:
journalctl -n 100 MESSAGE_ID=98e322203f7a4ed290d09fe03c09fe15
Эти команды помогают детализировать системный журнал, ориентируясь на ключевые идентификаторы сообщений. Используя возможности systemd и journalctl, можно эффективно управлять службами и получать информацию о причинах их неудач. Это критично для своевременного реагирования и устранения сбоев.
Важно отметить, что хранение кастомных(unit-файлов) в каталоге /usr/lib/ не является лучшей практикой. Здесь обычно располагаются файлы, управляемые пакетным менеджером. Для пользовательских системных файлов рекомендуется применять каталог /etc/systemd/system/ для того, чтобы избежать возможных конфликтов и случайных перезаписей.
Обобщая, осознание принципов работы systemd и использование мощных инструментов для мониторинга и диагностики позволяют обеспечить стабильность операций и своевременное реагирование на возникающие сбои. Такой подход помогает не только выявлять текущие проблемы, но и предотвращать их в будущем.