Inirestart ng aming watchdog ang mga serbisyo na sinadya naming ihinto

Ops2026-10-31

Isa sa aming watchdog ang nagsisimula ng anumang serbisyo namin na enabled ngunit hindi tumatakbo. Dalawang beses noong Oktubre, pinasimulan nito ang mga serbisyo na sinadya naming ihinto. Sa ikalawang pagkakataon, nakaranas ng mga error ang mga bisita sa isa sa aming mga site sa loob ng humigit-kumulang 45 minuto.

Bakit umiiral ang watchdog na iyon

Ang isang serbisyo na malinis na lumalabas kapag nakatanggap ng SIGTERM, halimbawa dahil pinatay ito ng pangalan ng isang bagay, ay hindi itinuturing na "failed" para sa systemd. Hindi ito ibinabalik ng Restart=on-failure, at hindi ito nililista ng systemctl --failed. Nanatiling patay ito hanggang sa mapansin ng isang tao. Kaya naman hinahanap ng watchdog ang mga serbisyo na enabled ngunit hindi tumatakbo, at pinapatakbo ang mga ito.

Ang problema ay mukhang eksaktong katulad ang isang serbisyo na iyong hininto nang manu-mano.

Ang unang pagkakataon

Noong 7 Oktubre, hininto namin ang isang video worker gamit ang systemctl stop noong 12:47 upang i-edit ang job queue nito. Noong 12:55, tumatakbo na naman ito: pinasimulan ito ng watchdog.

Ang ikalawang pagkakataon

Noong 21 Oktubre, kailangan namin ang memorya ng makina na nagse-serve rin ng dalawa sa aming mga site para sa isang model test. Pinatay ng isang script ang mga web app ng mga site, isang sync job at isang database container, muli gamit ang systemctl stop. Humigit-kumulang limang minuto ang lumipas, isang timer na binabantayan ang mga site, at noong 19:14 ang watchdog, ang nagbalik ng tunnel at ng mga web app.

Tumanggap na naman ng traffic ang tunnel, ngunit hindi makasagot ang mga web app: hawak ng model na sinusubukan ang 114 GiB ng memorya ng makina. Mula humigit-kumulang 19:14 hanggang 20:00, nakatanggap ng mga 502 error ang ilang bisita. Noong 20:00, dinedisable namin ang tunnel, ang mga web app at ang sync job, at hininto ang watch timer.

Ang patakaran na ginagamit namin ngayon

• I-pause ang isang serbisyo sa pamamagitan ng pag-disable dito: sudo systemctl disable --now <unit>. Ibinalik ito gamit ang sudo systemctl enable --now <unit>. Tinitingnan lamang ng aming watchdog ang mga enabled na serbisyo, kaya hindi nilalabagan ang isang disabled na serbisyo.
• I-pause ang lahat ng maaaring magbalik dito: ang tunnel sa harap nito at anumang timer na binabantayan ito.
• Ang maikling paghinto ay isang karera. Kung gagamit ka lamang ng stop, tapusin bago ang susunod na pagsusuri, na sa aming mga makina ay dumating sa loob ng ilang minuto.

Dalawa pang systemd trap mula sa parehong buwan

• systemctl mask --runtime ay walang ginagawa para sa unit file sa /etc/systemd/system. Ang mga unit sa /etc ay may mas mataas na priority kaysa sa runtime mask sa /run, kaya matagumpay ang command ngunit patuloy pa ring nagsisimula ang serbisyo. Upang mapigilan ang isang serbisyo, gumagamit kami ng drop-in na may ConditionPathExists=!/etc/<name>.hold: habang umiiral ang file na iyon, hindi magsisimula ang serbisyo, maging sa boot o sa pamamagitan ng kamay.
• systemctl is-active ay tinatawag na inactive ang isang tumatakbong oneshot service. Habang tumatakbo ang isang Type=oneshot service, ang estado nito ay "activating", kaya ipinapakita ng is-active ito at bumabalik ng 3. Ang loop na katulad ng while systemctl is-active --quiet job.service; do sleep 60; done, na nilalayong maghintay para sa nightly job, ay agad na lumalabas. Basahin sa halip ang estado: ang active, activating, reloading o deactivating ay nangangahulugang patuloy pa rin itong tumatakbo.

Factory Floor ay binabantayan ang mga naka-enable na serbisyo na hindi tumatakbo. Sa default, iniuulat lamang nito ang mga ito, at sinisimulan lamang ang mga ito kung buksan mo ang opsyon na iyon. Mula sa bersyon 1.0.3, sinasabi rin ng alerto nito kung paano i-pause ang isang serbisyo nang sinasadya, at sinasabi rin ng runbook nito ang parehong bagay.