Нашият watchdog рестартира услугите, които бяхме спрели умишлено

Операции2026-10-31

Един от нашите watchdogs стартира всяка от нашите услуги, която е активирана, но не работи. Два пъти през октомври той стартира услуги, които бяхме спрели умишлено. Втория път посетителите на един от сайтовете ни получиха грешки за около 45 минути.

Защо съществува този watchdog

Услуга, която излиза чисто при получаване на SIGTERM, например защото нещо я е убило по име, не се счита за „неуспяла“ от гледна точка на systemd. Restart=on-failure не я възстановява, а systemctl --failed не я изброява. Тя остава спряна, докато някой случайно не забележи. Затова watchdog-ът търси услуги, които са активирани, но не работят, и ги стартира.

Проблемът е, че услуга, която сте спрели ръчно, изглежда по същия начин.

Първият път

На 7 октомври спряхме видео обработващ процес с systemctl stop в 12:47 ч., за да редактираме опашката с задачи. В 12:55 ч. той вече работеше отново: watchdog-ът го беше стартирал.

Вторият път

На 21 октомври имахме нужда от паметта на машината, която обслужва и два от сайтовете ни, за тест на модел. Скрипт спря уеб приложенията на сайтовете, синхронизираща задача и контейнер с база данни, отново с systemctl stop. Около пет минути по-късно таймер, който наблюдава сайтовете, а в 19:14 ч. и watchdog-ът, възстановиха тунела и уеб приложенията.

Тунелът пое трафик отново, но уеб приложенията не можеха да отговорят: тестваният модел заемаше 114 GiB от паметта на машината. От около 19:14 ч. до 20:00 ч. някои посетители получаваха грешки 502. В 20:00 ч. деактивирахме тунела, уеб приложенията и синхронизиращата задача и спряхме таймера за наблюдение.

Правилото, което използваме сега

• Паузирайте услуга, като я деактивирате: sudo systemctl disable --now <unit>. Върнете я с sudo systemctl enable --now <unit>. Нашият watchdog разглежда само активирани услуги, така че деактивирана услуга остава на мира.
• Паузирайте всичко, което може да я върне: тунела пред нея и всеки таймер, който я наблюдава.
• Краткото спиране е надпревара. Ако използвате само stop, завършете преди следващата проверка, която на нашите машини идва в рамките на минути.

Още два капана на systemd от същите месеци

• systemctl mask --runtime не прави нищо за unit файл в /etc/systemd/system. Unit файловете в /etc имат приоритет пред временния mask в /run, затова командата завършва успешно, но услугата все пак стартира. За да задържим услуга, използваме drop-in с ConditionPathExists=!/etc/<name>.hold: докато този файл съществува, услугата няма да стартира, нито при зареждане, нито ръчно.
• systemctl is-active определя работеща oneshot услуга като неактивна. Докато Type=oneshot услуга работи, състоянието ѝ е "activating", затова is-active извежда това и връща 3. Цикъл като while systemctl is-active --quiet job.service; do sleep 60; done, предназначен да изчака нощна задача, излиза веднага. Вместо това четете състоянието: active, activating, reloading или deactivating всички означават, че все още работи.

Factory Floor наблюдава активирани услуги, които не работят. По подразбиране той само ги докладва и ги стартира, само ако включите тази опция. От версия 1.0.3 предупреждението му показва и как да спрете услуга умишлено, а runbook-ът му съдържа същото.