Watchdog Masih Ngecek Path Container yang Udah Nggak Ada
Migrasi watchdog Hermes ke host-native ternyata bukan cuma ganti path. Pelajaran soal git diff --quiet, set -euo pipefail, dan pola 0-token.
Ringkasan
Migrasi Hermes ke host-native nyaris kelar, tapi watchdog pagi masih menunjuk path container lama. Perbaikannya bukan sekadar ganti prefix; cek git, lokasi venv, dan set -euo pipefail ikut berubah, dan kombinasi guard itu bisa membuat kegagalan senyap terbaca sebagai hari sehat. Cek ukuran DB dan turn_log tetap dijaga agar alarm tetap bunyi.
Migrasi Hermes dari container ke host-native udah selesai. Container dimatiin, semua service jalan langsung di host. Tinggal satu file yang lolos dari cek saya: hermes-patch-watchdog.sh, script kecil yang tugasnya ngecas kesehatan runtime tiap pagi. Script itu masih setia mengarah ke /opt/hermes, path lama era container yang udah nggak ada. Ironisnya, watchdog adalah script yang harusnya paling aware soal perubahan lingkungan, tapi justru dia yang paling akhir kepikiran buat dipindah.
Bukan Sekadar Ganti Prefix Path
Kiraan awal saya memang sederhana: buka script, ganti /opt/hermes jadi path home, kelar. Ternyata pas diff lama dan baru saya bandingkan, ada tiga perilaku yang ikut berubah, bukan cuma alamat folder.
Pertama, makna cek git-nya geser. Dulu repo di /opt/hermes adalah tempat patch hidup, jadi git status --porcelain pada folder plugin langsung nunjukin patch ketimpa apa nggak. Sekarang repo-nya vanilla, patch saya taruh di branch terpisah. Repo bersih itu kondisi normal, bukan tanda bahaya. Versi baru makanya pakai git diff --quiet [3], yang mematikan semua output dan bikin exit status jadi 1 pas ada perbedaan, lalu cuma ngirim alarm kalau modifikasinya nyentuh folder plugin atau web.
Kedua, venv ikut pindah. Script lama manggil python dari .venv di dalam path container; versi baru nunjuk ke venv di dalam repo host-native. Kelihatan sepele, tapi kalau path python salah, cek turn_log bakal gagal tanpa pesan yang jelas.
Ketiga, ada set -euo pipefail yang nempel di versi baru. Dan ini bagian yang paling bikin saya mikir dua kali.
Jebakan set -euo pipefail di Pola 0-Token
Manual Bash ngejelasin set -e bakal bikin shell keluar segera pas ada pipeline yang balikin status non-zero [1], kecuali command-nya ada di dalam if, di sambungan dan-atau, atau beberapa pengecualian lain. pipefail nambahin aturan: nilai akhir sebuah pipeline ditentukan command paling kanan yang gagal [1]. Ditambah minus-u yang bikin variabel nggak keisi jadi error langsung [1]. Di atas kertas, ini pembagian tugas yang bagus buat script apa pun.
Masalahnya, watchdog ini jalan dengan pola 0-token: stdout kosong berarti aman, ada output berarti alarm. Kombinasi keduanya punya satu mode gagal yang licik. Kalau ada command di tengah script mati karena sebab kecil, misalnya file yang dicek lagi direname proses lain, set -e bisa motong script di situ juga. Sisa cek setelahnya nggak jalan, output tetep kosong, dan sistem lain baca itu sebagai hari yang sehat. Kegagalan yang nyamar jadi kesuksesan.
Solusinya bukan mbalik ke script tanpa guard, tapi bungkus tiap cek dalam kondisi eksplisit. Gagal yang disengaja dikasih output alarm; gagal yang nggak diperkirakan nggak boleh lolos diam-diam. Prinsipnya sederhana: untuk script yang kontraknya diam berarti sehat, lebih baik script-nya berisik pas error daripada diem dan bikin saya keliru percaya.
Yang Tetap Dijaga: Ukuran DB dan turn_log
Bagian inti cek nggak berubah, cuma dua hal. Pertama, ukuran memory_store.db plus file WAL-nya, alarm kalau lewat 500MB. Di mode WAL, perubahan di-append dulu ke file wal, terus dimasukin balik ke database lewat proses yang disebut checkpoint [2]. Checkpoint otomatisnya jalan pas file wal nyentuh 1000 halaman [2], jadi tumbuhnya wajar, tapi di mesin kecil tetep perlu diawasi biar nggak makan disk diam-diam.
Kedua, jumlah baris turn_log. Cap rotasinya 5000, dan alarmnya bunyi di 4800, pas udah nempel plafon. Angka-angka begini nggak ada di dokumentasi mana pun, murni kelakuan runtime sendiri, dan justru itu alasan script ini ada.
Satu hal yang sering dikira orang: script seperti ini jalan di atas systemd timer, padahal unit timer memang didesain buat nyalain service pas waktunya tiba [4]. Kebetulan di setup saya, dia jalan lewat cron internal Hermes dengan jadwal 0 8 * * * yang kebaca dari jobs.json lokal. Jalannya lewat mana nggak penting; yang penting alarmnya masih bunyi ke tempat yang benar.
Pelajaran yang saya bawa: pas pindah rumah, audit script yang nempel path absolut itu wajib, bukan sekadar find and replace. Soalnya script semacam ini satu-satunya yang beneran ngerti bentuk fisik sistem, dan justru dia yang paling gampang basi tanpa kelihatan.