Kontainer Mati 2 Bulan di Homelab, Uptime Kuma dan Beszel Tak Menangkapnya
INSIDERINDONESIA.COM — Sebuah kontainer Synology MCP server di homelab seorang pengguna dilaporkan mati selama dua bulan tanpa terdeteksi oleh alat monitoring populer seperti Uptime Kuma maupun Beszel. Kegagalan sebenarnya bukan terletak pada kontainer itu sendiri, melainkan pada alat peluncur berbasis uv yang rusak diam-diam setelah pembaruan pustaka Python. Kasus ini menyoroti celah nyata dalam pemantauan layanan yang berjalan lewat standard input.
Seorang pengguna homelab menemukan kontainernya sudah mati selama dua bulan saat melakukan audit rutin di Docker Desktop. Statusnya "Exited (0) 2 months ago" — kode keluar yang oleh Docker dianggap sebagai kondisi normal. Temuan itu awalnya tampak seperti akar masalah, sampai log kontainer dibaca lebih teliti.
Kontainer tersebut ternyata adalah percobaan pertama yang sudah lama ditinggalkan. Ia dijalankan tanpa input stream interaktif, sehingga server yang berkomunikasi lewat standard input langsung menutup pintu dan berhenti dalam hitungan detik. Kontainer itu tidak pernah sekali pun melayani Claude.
Kegagalan Sesungguhnya Ada di Baris Konfigurasi
Peluncur asli Synology MCP server ternyata cuma satu baris entri di konfigurasi Claude Desktop yang menjalankannya dengan uv. Di sinilah masalah sebenarnya bersembunyi. Setiap kali Claude Desktop menyalakan server, uv membangun lingkungan Python dari file requirements proyek.
File itu meminta pustaka mcp dengan versi minimal 1.28.0 tanpa batas atas. Pada 28 Juli, pustaka mcp Python merilis versi 2.0.0 dan menghapus API yang jadi fondasi server tersebut. Sejak saat itu, setiap peluncuran menarik versi baru dan server mati sebelum sempat menyentuh NAS.
Akun DSM yang dipakai server untuk login juga sudah hilang. Artinya, bahkan peluncur yang berfungsi pun akan ditolak di pintu. Pengguna kemudian membuat ulang akun tersebut dan mengunci versi pustaka di bawah 2.0 — sejak itu semuanya berjalan normal.
Empat Pekan Sinyal yang Terlewat
Petunjuk kegagalan sudah muncul sejak lama. Sebuah tugas mingguan yang memunculkan ide artikel dari catatan lab selalu membuka laporannya dengan baris housekeeping. Pada 25 Agustus, 1 September, 8 September, dan 15 September, baris itu berbunyi sama: tidak ada Synology MCP di sesi ini, kembali bekerja dari salinan lokal.
Kata "lagi" muncul empat pekan berturut-turut. Pengguna mengaku membacanya sekilas dan melewatkannya begitu saja.
Proxmox: Tanpa Backup, Notifikasi ke Email Hantu
Sisi Proxmox dari audit justru lebih memalukan. Tidak ada pekerjaan backup sama sekali di node tersebut. Beberapa kontainer memang punya snapshot ZFS, dan pengguna sempat menganggapnya sebagai "sudah ter-backup" — padahal bukan.
Pemeriksaan pembaruan harian juga gagal selama 11 hari karena langganan Proxmox habis, dan repositori enterprise mulai menolak node. Proxmox memperingatkan setiap pagi, tetapi peringatan itu hanya dikirim ke mail-to-root, satu-satunya target notifikasi yang dikonfigurasi — sebuah kotak surat yang tidak pernah dibuka siapa pun.
Mengapa Uptime Kuma dan Beszel Tak Bisa Menangkapnya
Pengguna membangun tumpukan monitoring yang sengaja dibuat kecil: tiga LXC mungil dari skrip helper komunitas Proxmox VE. Uptime Kuma memeriksa apakah setiap layanan benar-benar merespons, Beszel memantau kesehatan mesin, dan ntfy mengirim semua peringatan ke ponsel, termasuk alarm dari Proxmox sendiri.
Namun tak satu pun dari alat itu mampu menangkap peluncur yang rusak. Uptime Kuma memeriksa layanan yang mendengarkan di sebuah port, sementara MCP server yang berkomunikasi lewat standard input tidak mendengarkan port apa pun. Beszel mencatat apa yang sedang berjalan, dan server yang mati di detik pertama tidak akan pernah muncul.
Pemeriksaan yang paling penting akhirnya berupa skrip Python kecil. Skrip itu menyalakan setiap MCP server di konfigurasi Claude Desktop dengan perintah yang sama seperti klien, menyelesaikan handshake, lalu meminta setiap server mendaftar alatnya. Hasilnya kemudian dikirim ke push monitor Uptime Kuma — jika skrip itu sendiri berhenti berjalan, kesunyiannya memicu peringatan.
Berikut hasil pemeriksaan terakhir: technitium-primary merespons dalam 1,7 detik dengan 39 alat, technitium-secondary 0,2 detik dengan 39 alat, Home Assistant 21,0 detik dengan 77 alat, proxmox-iac 2,8 detik dengan 32 alat, proxmox-full 1,6 detik dengan 3 alat, dan synology 1,9 detik dengan 77 alat.
Sebelum perbaikan, baris synology gagal dalam waktu kurang dari dua detik. Skrip itu kini berjalan setiap 30 menit.
