Нашиот watchdog ги рестартира сервисите кои намерно ги запревме

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

Еден од нашите watchdogs стартува секој од нашите сервиси што е овозможен, но не работи. Двапати во октомври стартува сервиси кои намерно ги запревме. Вториот пат, посетителите на еден од нашите сајтови добиваа грешки околу 45 минути.

Зошто тој watchdog постои

Сервис кој чисто излегува кога добива SIGTERM, на пример затоа што нешто го убило по име, не е „неуспешен“ (failed) според 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 имаат приоритет над runtime-маската во /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, неговото известување исто така вели како намерно да паузирате услуга, а неговата процедура за постапување вели исто.