Задание по расписанию не выполнилось: проверяем таймер systemd

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

Примеры предназначены для Linux с systemd. Они читают состояние и описание unit, не запускают задание повторно. Начните со списка, включая неактивные таймеры:

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

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

Если пользовательского менеджера нет в текущем сеансе, команда может не подключиться. Это свойство окружения, а не подтверждение поломки всего планировщика.

Проверьте условия календарного или относительного запуска и указанный unit. Если имя службы не задано явно, у таймера обычно используется соответствующее базовое имя. Не предполагайте, что любое описание с названием «backup» выполняет именно нужную резервную копию.

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

Пример: таймер сработал вовремя, но программа не смогла прочитать файл настроек. Исправлять время запуска бесполезно — расписание уже выполнило свою часть. Другой случай: служба всё ещё работает, потому что предыдущая обработка затянулась. Это повод проверить длительность операции, а не запускать несколько копий вручную.

Проверьте часовой пояс сервера и то, под каким пользователем выполняется задача. Ручной запуск в интерактивном терминале может получать другие переменные, рабочий каталог и права. Поэтому фраза «у меня команда работает» не подтверждает исправность служебного запуска.

В отчёте укажите имена timer и service, ожидаемое и фактическое время, результат службы и факт появления конечного результата. Повторный ручной запуск допустим только после оценки повторяемости операции: отправка писем или выгрузка заказов может создать дубли. Диагностика завершается тогда, когда понятно, сорвалось расписание или само выполнение.

The timer is marked as active, but the catalog export has not appeared. This is possible: the timer controls the launch moment, while a separate service performs the work. Both components must be checked. Otherwise, a green schedule status may hide an error in the task itself.

Examples are for Linux with systemd. They read the unit state and description without re-running the task. Start with the list, including inactive timers:

Check the last trigger, next run, and linked service. The time of the next event is not a guarantee of a successful result. Also note that the system manager list does not automatically show all user timers.

For current user timers, use a separate command:

If the user manager is not present in the current session, the command may fail to connect. This is an environment property, not confirmation that the entire scheduler has failed.

Check the conditions for calendar-based or relative startup and the specified unit. If the service name is not explicitly set, the timer typically uses the corresponding base name. Do not assume that any description containing the word "backup" performs the specific backup you need.

Take the service name from the list and examine its state and logs for the relevant period. For a one-time job that completed successfully, an inactive state may be normal. More important are the exit code and the expected outcome: a generated report, a processed package, or an application record.

Example: the timer triggered on time, but the program could not read the configuration file. Fixing the startup time is pointless—the schedule has already done its part. Another case: the service is still running because the previous processing took too long. This is a reason to check the operation duration, not to manually launch multiple copies.

Check the server time zone and the user under which the task runs. Manually launching in an interactive terminal may receive different environment variables, a working directory, and permissions. Therefore, the phrase "my command works" does not confirm that the service launch is functioning correctly.

In the report, specify the timer and service names, the expected and actual times, the service result, and whether the final result appeared. A repeated manual run is permitted only after evaluating the operation's repeatability: sending emails or exporting orders can create duplicates. Diagnostics conclude once it is clear whether the schedule was missed or the execution itself failed.