Тайм-ауты systemd: запуск, остановка и продление требуют отдельных условий
Фотография конкретного исполнения не приложена.
Инициализация хранилища и завершение службы могут занимать разное время. TimeoutStartSec ограничивает запуск, TimeoutStopSec относится к остановке. Универсальный большой таймер затрудняет обнаружение зависания, а слишком короткий способен прервать штатную обработку при ожидаемой нагрузке.
Для Type=oneshot справочник 262 отдельно отмечает отключённый по умолчанию тайм-аут запуска. Поэтому нельзя переносить ожидания от обычного демона на обслуживающее задание без просмотра эффективных настроек. Стандартные значения менеджера и переопределения unit тоже требуют фиксации для конкретного узла.
Службы, поддерживающие уведомления, могут отправлять EXTEND_TIMEOUT_USEC. Первое сообщение должно прийти до истечения исходного срока, а последующие — в пределах объявленного интервала. Позднее сообщение не является гарантированным спасением уже завершённой менеджером операции. Протокол должен быть реализован программой и связан с фактическим продвижением работы.
Приёмка измеряет нормальный старт, медленную инициализацию, остановку с незавершённой записью и искусственное зависание. Проверяют, какие данные приложение сохраняет до принудительного завершения. Для аварии watchdog может потребоваться отдельный срок формирования core dump через TimeoutAbortSec. Увеличение этого срока не подтверждает целостность прикладных данных и не освобождает от определения допустимого времени восстановления сервиса.
Основание — Official systemd manual edition262, cited sections only, разделы systemd.service TimeoutStartSec; TimeoutStopSec; TimeoutAbortSec. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Материал относится к справочникам systemd 262. Установленные Linux-дистрибутив, сборка systemd и возможности ядра не проверялись; изменения служб и настроек не выполнялись.
