status=212/TIMERSLACK в systemd
Код 212/TIMERSLACK относится к параметру TimerSlackNSec=, который разрешает ядру объединять близкие пробуждения процесса для экономии энергии. Код встречается редко: параметр используют единицы, а отказать он может в основном из-за неразумного значения.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Значение слишком велико или задано в неверных единицах
Параметр принимает время в наносекундах или с указанием единицы. Запись без единицы читается как наносекунды, поэтому «50» — это 50 нс, а не 50 мс, и попытка записать заведомо гигантское число заканчивается отказом.
-
Окружение не позволяет менять допуск таймеров
В части контейнеров и при внешней фильтрации системных вызовов вызов prctl для этого параметра запрещён.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Показывает шаг TIMERSLACK и причину.
journalctl -xeu myapp.service --no-pager -n 20Действующее значение параметра.
systemctl show myapp.service -p TimerSlackNSecРешение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Параметр принимает время в наносекундах или с указанием единицы. Запись без единицы читается как наносекунды, поэтому «50» — это 50 нс, а не 50 мс, и попытка записать заведомо гигантское число заканчивается отказом.
- Как проверить
-
Посмотрите действующее значение.
systemctl show myapp.service -p TimerSlackNSec
- Как исправить
-
Указывайте единицу явно:
TimerSlackNSec=50ms. Для большинства служб параметр вовсе не нужен — его стоит убрать.
- Почему происходит
- В части контейнеров и при внешней фильтрации системных вызовов вызов prctl для этого параметра запрещён.
- Как проверить
-
Проверьте тип окружения.
systemd-detect-virt journalctl -xeu myapp.service -n 20 --no-pager
- Как исправить
- Уберите параметр из unit-файла: он влияет только на энергосбережение и не критичен для работы службы.
Пример вывода
Отказ на шаге настройки допуска таймеров. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
× myapp.service - My application
Active: failed (Result: exit-code) since Mon 2026-09-14 19:40:18 MSK; 1s ago
Process: 16900 ExecStart=/usr/local/bin/myapp (code=exited, status=212/TIMERSLACK)
systemd[16900]: myapp.service: Failed at step TIMERSLACK spawning /usr/local/bin/myapp: Invalid argument
Связанные ошибки
- status=201/NICE в systemd Код 201/NICE: systemd не смог выставить приоритет процесса из Nice=. Обычно мешает предел LimitNICE или отсутствие прав.
- status=207/SIGNAL_MASK в systemd Код 207/SIGNAL_MASK: systemd не смог установить маску сигналов для нового процесса. Редкий код, признак проблем в окружении.
- Failed to parse calendar expression: ошибка в OnCalendar systemd не разбирает календарное выражение таймера. Правила записи OnCalendar и проверка через systemd-analyze calendar.
- clocksource: Marking clocksource unstable Ядро переключило источник времени. Службы видят скачки времени, таймеры срабатывают не тогда, когда ожидалось.
- signal=FPE (status=8/FPE) в systemd Процесс службы завершён сигналом FPE: арифметическая ошибка, чаще всего деление на ноль в целочисленной арифметике.
- status=213/SECUREBITS в systemd Код 213/SECUREBITS: не удалось выставить биты безопасности процесса из SecureBits=. Редкий параметр, требующий прав.
- status=220/SETSID в systemd Код 220/SETSID: systemd не смог создать новый сеанс процесса. Редкий код, чаще всего связан с окружением запуска.
- status=221/CONFIRM в systemd Код 221/CONFIRM: запуск отменён вручную в режиме подтверждения. Это не сбой, а следствие параметра ядра systemd.confirm_spawn.
Источники
-
systemd.exec(5)
212 EXIT_TIMERSLACK: не удалось настроить допуск таймеров, см. TimerSlackNSec=. -
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Проверено на unit с TimerSlackNSec без единицы измерения.