Systemctl - list-timers — просмотр списка таймеров - 2026

Published: 2026-09-27

systemctl list-timers — команда systemd, которая показывает все таймеры, загруженные в текущий менеджер, в порядке их следующего срабатывания. Для каждого таймера выводятся время ближайшего запуска, сколько осталось ждать, время последнего запуска и имя сервиса, который этот таймер активирует. Это самый быстрый способ ответить на два вопроса администратора: «что вообще запланировано на этом сервере» и «почему моя задача по расписанию молча не выполняется».

Команда появилась вместе с подкомандой `list-timers` в systemd версии 209 и работает без root: она лишь опрашивает менеджер systemd через D-Bus. Root (или членство в группах `wheel`, `adm`, `systemd-journal`) нужен уже для чтения системного журнала, куда вы пишете логи задач.

Обзор

Ниже — карточка с ключевыми параметрами команды: синтаксис, источник данных, состав колонок и требования к доступу.

Ключевые параметры
Параметр	Значение
Синтаксис	systemctl list-timers [PATTERN…]
Менеджер	systemd, подкоманда доступна с версии 209
Источник данных	список unit-ов типа timer в памяти менеджера
Порядок сортировки	по времени следующего срабатывания
Колонки	NEXT, LEFT, LAST, PASSED, UNIT, ACTIVATES
Права	для списка не нужны; для чтения журнала — root либо wheel, adm, systemd-journal
Логи запусков	journalctl -u имя-сервиса.service

Если таймеров в системе нет, команда просто не выведет ни одной строки — это нормально, а не ошибка. Если же список пуст, а задачи точно должны быть, скорее всего, таймеры не активированы: их нужно один раз включить через `systemctl enable --now`.

Что показывает вывод

Типичный вывод выглядит так: четыре таймера, у каждого видно прошлое и будущее срабатывание, а в последней колонке — сервис, который будет запущен.

$ systemctl list-timers

NEXT                        LEFT     LAST                        PASSED   UNIT                          ACTIVATES
Sun 2026-09-27 22:00:00 MSK 5min     Sun 2026-09-27 21:00:00 MSK  1h ago   logrotate.timer               logrotate.service
Mon 2026-09-28 00:17:24 MSK 2h 17min Sun 2026-09-27 00:17:24 MSK  22h ago  apt-daily.timer               apt-daily.service
Sun 2026-09-28 06:47:31 MSK 8h 47min Sun 2026-09-27 06:47:31 MSK  15h ago  systemd-tmpfiles-clean.timer  systemd-tmpfiles-clean.service
Sun 2026-09-27 21:32:10 MSK 32s      Sun 2026-09-27 21:27:10 MSK  5min    fstrim.timer                  fstrim.service

Расшифровка колонок — из руководства systemctl:

Колонка	Что означает
NEXT	время следующего срабатывания таймера
LEFT	сколько времени осталось до следующего срабатывания
LAST	время последнего срабатывания таймера
PASSED	сколько времени прошло с последнего срабатывания
UNIT	имя самого таймера
ACTIVATES	имя сервиса, который таймер запускает

В примере выше видно, что `fstrim.timer` сработает через 32 секунды, а `apt-daily.timer` последний раз запускался 22 часа назад. Именно эта пара колонок `LAST` и `PASSED` и есть главный инструмент диагностики: если `PASSED` растёт не по расписанию, значит таймер не активен, а если `LAST` свежий, но задачи нет в логах — проблема уже в самом сервисе.

В некоторых случаях вместо времени выводится прочерк. Так выглядят таймеры, которые уже сработали и больше не могут сработать: в официальном примере systemctl строка `ureadahead-stop.timer` показывает прочерки в колонках NEXT и LEFT. Аналогично прочерк в LAST означает, что таймер после старта менеджера ещё ни разу не срабатывал.

Полезные ключи

Базовый вызов показывает только активные таймеры. Остальные случаи закрываются флагами:

# все таймеры, включая неактивные и остановившиеся
systemctl list-timers --all

# только конкретный таймер или группа по маске
systemctl list-timers logrotate.timer
systemctl list-timers apt-daily.timer fstrim.timer

# таймеры в определённом состоянии
systemctl list-timers --state=running

# без постраничного вывода и без заголовка колонок — удобно для скриптов
systemctl list-timers --no-pager --no-legend

# таймеры пользовательского менеджера, а не системного
systemctl --user list-timers

Флаги `--all` и `--state=` упоминаются в руководстве systemctl как штатные спутники `list-timers`. Пара `--no-pager` и `--no-legend` особенно полезна в автоматизации: первый убирает пайзер `less`, второй — строку заголовка, из-за которой разбор вывода ломается.

Для машинного чтения удобнее вообще не парсить таблицу, а запросить конкретное свойство таймера:

systemctl show logrotate.timer -p NextElapseUSecRealtime -p LastTriggerUSec

Как читать вывод

Первое, на что стоит смотреть, — колонка UNIT. Имя файла в ней всегда заканчивается на `.timer`, а рядом, в ACTIVATES, стоит сервис с тем же именем, но без суффикса `.service` (если в секции `[Timer]` не задан параметр `Unit=`). Файлы unit-ов таймеров лежат в каталогах `/usr/lib/systemd/system`, `/etc/systemd/system` и `/run/systemd/system`, а посмотреть конкретный файл вместе с drop-in-оверрайдами позволяет `systemctl cat`.

Второе — расхождение между `NEXT` и ожиданием. Таймер не обязан сработать точно в указанную секунду. По умолчанию `AccuracySec=` равен одной минуте, и внутри этого окна момент срабатывания сдвигается случайно, но одинаково для всех таймеров, — так systemd объединяет пробуждения процессора и экономит энергию. Дополнительный сдвиг задаёт `RandomizedDelaySec=`, который растягивает однотипные задачи по интервалу, чтобы они не стартовали одновременно.

Третье — пустые значения в `LAST` у таймеров с монотонными правилами. Таймер на `OnUnitActiveSec=15min` отсчитывает время от последней активации сервиса, поэтому до первого запуска в колонке `LAST` будет прочерк, и это не поломка.

Таймер не сработал: диагностика

Если задача должна была выполниться, а в списке её нет или `PASSED` растёт, идите по шагам — каждый следующий пункт опирается на результат предыдущего.

Проверьте, что таймер вообще активирован. Команда `systemctl is-enabled имя.timer` отвечает, включён ли он автозапуском, а `systemctl is-active имя.timer` — работает ли он прямо сейчас. Если таймер создан, но не запущен, нужен `systemctl enable --now имя.timer`.
Убедитесь, что таймер виден в списке. Если в выводе `systemctl list-timers` его нет, проверьте имя файла, каталог размещения и выполните `systemctl daemon-reload`. Правила из секции `[Timer]` должны разбираться без ошибок — это показывает `systemd-analyze verify имя.timer`.
Проверьте, когда таймер срабатывает на самом деле. Выражение `OnCalendar=` можно протестировать отдельно: `systemd-analyze calendar 'Mon..Fri 09:00'` покажет нормализованную форму и ближайшие моменты срабатывания. Так вы сразу увидите опечатку в часах или днях недели.
Сверьте фактическое время последнего запуска с ожидаемым. Расхождение больше минуты объясняется `AccuracySec=` и `RandomizedDelaySec=`; их можно уменьшить в самом unit-файле, если точность действительно важна.
Посмотрите журнал сервиса, а не таймера. Таймер только инициирует запуск, поэтому `journalctl -u имя-сервиса.service -n 50` покажет либо успешное выполнение, либо ошибку. Частая картина: таймер работает исправно, а сервис падает с ненулевым кодом возврата.
Убедитесь, что часы идут правильно. Для таймеров с `OnCalendar=` важно реальное время системы: `timedatectl status` покажет, синхронизировано ли оно с источником времени.

ℹ️ Информация
Для таймеров с OnCalendar= полезно включать Persistent=true. Тогда время последнего срабатывания сохраняется на диске, и при загрузке сервис запускается сразу, если он должен был отработать, пока система была выключена.

Сбросить сохранённый таким образом отметку времени можно отдельно, не трогая остальные данные unit-а:

systemctl clean --what=state имя.timer

Свой таймер: пример unit-файла

Таймер — это отдельный файл с секцией `[Timer]` и партнёрский файл с секцией `[Service]`. Минимальный рабочий вариант выглядит так:

[Unit]
Description=Ежедневный бэкап проекта

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=15min
AccuracySec=1min

[Install]
WantedBy=timers.target

Обратите внимание на две особенности. Первая: правило `OnCalendar=daily` — это сокращение для полной формы `*-*-* 00:00:00`, а сам таймер по умолчанию активирует сервис с тем же именем без суффикса, то есть `backup.service`. Вторая: `Persistent=true` работает только с календарными таймерами и компенсирует запуск после простоя сервера.

Файл нужно положить в `/etc/systemd/system/`, перечитать конфигурацию и включить таймер:

systemctl daemon-reload
systemctl enable --now backup.timer
systemctl list-timers backup.timer

Если логика расписания сложнее простого интервала, доступны монотонные правила: `OnBootSec=5min` отсчёт от загрузки, `OnActiveSec=` от активации самого таймера, `OnUnitActiveSec=15min` от последнего запуска сервиса, `OnUnitInactiveSec=` от его остановки. Их можно комбинировать с `OnCalendar=` в одном файле, и срабатывание произойдёт по любому из условий.

Сравнение

На системе с systemd таймеры соседствуют с тремя другими механизмами расписания, и у каждого своя зона ответственности:

Инструмент	Что показывает	Особенности
systemctl list-timers	таймеры systemd: следующее и последнее срабатывание	есть история запусков, вывод сортируется по времени
crontab -l	crontab текущего пользователя	без истории, точность до минуты, нужна настройка MAILTO для отчётов
/etc/crontab и /etc/cron.d	системные расписания cron	в /etc/cron.d обязательно указывается пользователь, в /etc/crontab — нет
anacrontab	задачи по интервалу с догоняющим запуском	cron пропускает пропущенное, anacron выполняет при следующем старте

Вывод из таблицы простой: `systemctl list-timers` — единственный из этих инструментов, который показывает, когда задача запускалась в последний раз. Именно поэтому при расследовании «ничего не работает» начинают именно с него, а расписания cron при этом остаются слепой зоной — их состояние приходится оценивать по логам и косвенным признакам.

FAQ

Чем NEXT отличается от LEFT? NEXT — абсолютное время следующего срабатывания в местном часовом поясе, LEFT — относительная величина «сколько осталось ждать». В документации systemctl колонка LEFT может выводиться и с суффиксом `left`, например `1min 14s left`.

Почему в колонке LAST стоит прочерк? Это значит, что таймер после старта менеджера ещё ни разу не срабатывал. Чаще всего так ведут себя таймеры с монотонными правилами вида `OnUnitActiveSec=`, у которых отсчёт идёт от первого фактического запуска сервиса.

Нужен ли root, чтобы выполнить list-timers? Нет, сама команда работает от обычного пользователя, поскольку только читает состояние менеджера. Повышенные права понадобятся для `journalctl` по системному журналу либо для `systemctl enable` и `start`.

Таймер есть в списке, но задачи в логах нет. Что делать? Проверьте имя сервиса в колонке ACTIVATES и запросите его журнал напрямую: `journalctl -u имя-сервиса.service`. Если сервис завершился с ошибкой, таймер отработал корректно, а проблема уже внутри самой задачи.

Как убрать сохранённое время для Persistent=? Выполните `systemctl clean --what=state имя.timer` — команда очищает именно файл отметки времени, который ведёт таймер с включённым `Persistent=`. Руководство systemctl отдельно предупреждает, что её стоит выполнить перед удалением таймера из системы.

Почему время срабатывания отличается от заданного в минутах? По умолчанию `AccuracySec=` равен одной минуте: внутри этого окна systemd сдвигает момент случайно, но одинаково для всех локальных таймеров, чтобы не будить процессор по отдельности. Для максимальной точности параметр ставят в `1us`, помня о `TimerSlackNSec=` в конфигурации менеджера.

Итог

`systemctl list-timers` — короткая команда с большим диагностическим потенциалом. Она показывает весь план запусков systemd на сервере, с временем последнего и ближайшего срабатывания, и по этим двум колонкам сразу понятно, где затык: таймер выключен, расписание неверно, время сдвигается настройками точности — или таймер работает исправно, а падает сам сервис. Дальше остаётся переключиться с `list-timers` на `journalctl -u` и смотреть уже не расписание, а результат его выполнения.

Источники

×

← В главную