Watchdog kami me-restart layanan yang kami hentikan secara sengaja

Ops2026-10-31

Salah satu watchdog kami memulai layanan mana pun yang diaktifkan tetapi tidak berjalan. Dua kali pada bulan Oktober, ia memulai layanan yang kami hentikan secara sengaja. Pada kejadian kedua, pengunjung salah satu situs kami mengalami error selama sekitar 45 menit.

Mengapa watchdog itu ada

Layanan yang keluar dengan bersih saat menerima SIGTERM, misalnya karena sesuatu dihentikan berdasarkan namanya, tidak dianggap "gagal" oleh systemd. Restart=on-failure tidak mengembalikannya, dan systemctl --failed tidak mencantumkannya. Layanan itu tetap mati sampai seseorang kebetulan menyadarinya. Jadi, watchdog mencari layanan yang diaktifkan tetapi tidak berjalan, lalu memulainya.

Masalahnya adalah layanan yang Anda hentikan secara manual terlihat persis sama.

Kejadian pertama

Pada 7 Oktober, kami menghentikan worker video dengan systemctl stop pada pukul 12:47 untuk mengedit antrean kerjanya. Pada pukul 12:55, layanan itu sudah berjalan lagi: watchdog telah memulainya.

Kejadian kedua

Pada 21 Oktober, kami membutuhkan memori mesin yang juga melayani dua situs kami untuk pengujian model. Sebuah skrip menghentikan web app situs, job sinkronisasi, dan kontainer database, lagi-lagi dengan systemctl stop. Sekitar lima menit kemudian, sebuah Timer yang memantau situs, dan pada pukul 19:14 watchdog, mengembalikan tunnel dan web app.

Tunnel kembali menerima trafik, tetapi web app tidak dapat merespons: model yang diuji menahan 114 GiB memori mesin. Dari sekitar pukul 19:14 hingga 20:00, sebagian pengunjung mendapat error 502. Pada pukul 20:00, kami menonaktifkan tunnel, web app, dan job sinkronisasi, lalu menghentikan Timer pemantau.

Aturan yang kami gunakan sekarang

• Jeda layanan dengan menonaktifkannya: sudo systemctl disable --now <unit>. Kembalikan dengan sudo systemctl enable --now <unit>. Watchdog kami hanya melihat layanan yang diaktifkan, sehingga layanan yang dinonaktifkan dibiarkan.
• Jeda semua yang dapat mengembalikannya: tunnel di depannya dan Timer apa pun yang memantaunya.
• Penghentian singkat adalah balapan. Jika Anda hanya menggunakan stop, selesaikan sebelum pemeriksaan berikutnya, yang pada mesin kami terjadi dalam hitungan menit.

Dua jebakan systemd lain dari bulan yang sama

• systemctl mask --runtime tidak berpengaruh pada unit file di /etc/systemd/system. Unit di /etc memiliki prioritas lebih tinggi daripada mask runtime di /run, sehingga perintah berhasil dan layanan tetap berjalan. Untuk menahan layanan, kami menggunakan drop-in dengan ConditionPathExists=!/etc/<name>.hold: selama file tersebut ada, layanan tidak akan berjalan, baik saat boot maupun secara manual.
• systemctl is-active menyebut layanan oneshot yang sedang berjalan sebagai inactive. Saat layanan Type=oneshot berjalan, statusnya adalah "activating", sehingga is-active menampilkan status tersebut dan mengembalikan nilai 3. Loop seperti while systemctl is-active --quiet job.service; do sleep 60; done, yang dimaksudkan untuk menunggu pekerjaan malam hari, langsung keluar. Baca statusnya sebagai gantinya: active, activating, reloading atau deactivating semuanya berarti layanan masih berjalan.

Factory Floor memantau layanan yang diaktifkan tetapi tidak berjalan. Secara default, ia hanya melaporkannya, dan hanya menjalankannya jika Anda mengaktifkan opsi tersebut. Sejak versi 1.0.3, peringatannya juga menjelaskan cara menjeda layanan secara sengaja, dan runbook-nya menyebutkan hal yang sama.