Script Mati Setelah Tutup SSH? Jadikan Unit systemd

Script-nya dijalanin lewat SSH, jalan mulus. Sesi ditutup, prosesnya ikut mati.

Diakalin pakai nohup atau screen, jalan lagi. Sampai servernya direstart — dan nggak ada yang inget buat ngidupin lagi sampai ada pelanggan yang ngeluh.

Kenapa nohup dan screen bukan jawabannya

Keduanya emang nahan proses dari matinya sesi. Tapi tiga hal yang nggak mereka kerjain:

• Nyala lagi setelah server reboot. Nggak ada yang inget, dan biasanya baru ketahuan berhari-hari kemudian.
• Ngidupin lagi kalau prosesnya crash. Mati ya mati.
• Nyimpen lognya di tempat yang bisa dicari. Keluaran nyasar ke nohup.out di folder mana pun Anda kebetulan berada waktu itu.

systemd ngerjain ketiganya, dan berkasnya cuma belasan baris.

Unit paling sederhana yang sudah benar

Simpan di /etc/systemd/system/pemantau.service:

[Unit]
Description=Pemantau perangkat pelanggan
After=network-online.target

[Service]
Type=simple
User=corenet
WorkingDirectory=/opt/pemantau
ExecStart=/usr/bin/python3 /opt/pemantau/jalan.py
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Lalu:

systemctl daemon-reload
systemctl enable --now pemantau

enable bikin dia nyala tiap boot; --now mulai sekarang juga tanpa nunggu reboot.

Empat baris yang paling sering salah

ExecStart wajib jalur mutlak. systemd nggak pakai PATH seperti shell Anda. python3 doang bakal gagal dengan pesan No such file or directory yang nyesatin — seolah script-nya yang hilang, padahal penafsirnya yang nggak ketemu. Ini persis masalah yang sama dengan cron yang gagal jalan.

WorkingDirectory nggak diwarisi. Script yang mbuka data/konfigurasi.json dengan jalur relatif bakal nyari dari /, bukan dari foldernya sendiri.

User jangan dikosongin. Tanpa itu, layanannya jalan sebagai root. Kalau script-nya nulis berkas, berkasnya jadi milik root dan bikin masalah izin buat proses lain.

Type harus cocok sama kelakuan program. Type=simple berarti program tetap jalan di latar depan. Kalau program Anda ngedaemonin dirinya sendiri lalu keluar, systemd nyangka dia mati dan bakal ngidupin ulang terus-menerus. Buat program semacam itu pakai Type=forking.

Environment: satu jebakan yang tidak kelihatan

Layanan systemd hampir nggak punya environment. Tidak ada PATH seperti punya Anda, dan tidak ada variabel dari .bashrc maupun .profile.

Isi eksplisit:

Environment=TZ=Asia/Jakarta
EnvironmentFile=/opt/pemantau/env

EnvironmentFile isinya KUNCI=nilai per baris, dan lebih baik daripada nulis kredensial langsung di unit — berkas unit biasanya kebaca semua pengguna.

Lognya di journal, bukan di berkas

Keluaran standar dan error langsung ketangkep:

journalctl -u pemantau -f
journalctl -u pemantau --since "1 hour ago"
journalctl -u pemantau -p err

Nggak perlu nulis rotasi log sendiri, dan nggak ada nohup.out yang ngegembung sampai memenuhi disk.

Kalau jadwalnya berkala, timer lebih baik daripada cron

Buat pekerjaan yang jalan tiap sekian waktu, timer systemd punya dua kelebihan yang sering menentukan: Persistent=true ngejalanin pekerjaan yang kelewat waktu server mati, dan lognya masuk journal yang sama dengan layanan lain.

Cron tetap lebih sederhana buat pekerjaan yang mandiri dan sepele. Timer lebih baik begitu pekerjaan itu punya ketergantungan atau perlu dilacak.

Generator Unit systemd nyusun berkas unit lengkap dengan Restart, User, dan blok environment-nya, sekalian nyiapin timer kalau pekerjaannya berkala.

Bacaan lanjutan: Cron tidak jalan padahal perintahnya benar — akar masalahnya sama persis, dan 502 Bad Gateway di Nginx buat layanan yang mati diam-diam di belakang web server.