Server Solusi – Ketika sebuah service Linux gagal berjalan, perintah seperti systemctl restart nginx atau systemctl start mysql mungkin berakhir dengan pesan Job for ... failed. Pesan tersebut memberi tahu bahwa operasi gagal, tetapi belum tentu menjelaskan akar masalahnya.

Pada VPS yang menjalankan website, kegagalan service bisa berdampak langsung pada akses HTTP, koneksi database, proses aplikasi, hingga layanan email. Karena itu, langkah pertama bukan mengulang restart berkali-kali, melainkan mencari tahu apa yang membuat systemd gagal menjalankan service tersebut.

Saya tidak memiliki log server atau hasil pengujian nyata untuk kasus tertentu. Panduan ini menggunakan skenario troubleshooting umum agar kamu dapat memeriksa kondisi server sendiri, mengumpulkan bukti, dan menentukan perbaikan yang sesuai tanpa menebak penyebabnya.

Bagaimana cara mencari penyebab service failed?

Untuk mencari penyebab systemctl service failed, jalankan systemctl status nama-service --no-pager -l untuk melihat status dan pesan error, kemudian gunakan journalctl -u nama-service -b --no-pager untuk membaca log service pada boot saat ini.

Ganti nama-service dengan unit yang bermasalah, misalnya nginx, mysql, atau php8.3-fpm. Setelah menemukan error yang relevan, periksa konfigurasi, dependensi, permission, port, atau resource sistem sesuai petunjuk log. Jangan langsung menghapus file PID, mengubah permission secara luas, atau mematikan firewall sebelum penyebabnya diketahui.

Memahami arti systemctl service failed

systemctl adalah utilitas untuk mengelola unit yang ditangani oleh systemd. Unit dapat berupa service, timer, mount, socket, dan jenis resource lainnya. Pada kasus ini, fokusnya adalah unit bertipe service.

Ketika status service menunjukkan failed, artinya systemd mencatat bahwa unit mengalami kegagalan. Namun, status itu sendiri bukan diagnosis lengkap.

Beberapa kemungkinan penyebabnya antara lain:

• File konfigurasi aplikasi mengandung kesalahan sintaks.

• Port yang dibutuhkan sudah digunakan proses lain.

• File executable atau dependensi tidak tersedia.

• User service tidak memiliki akses ke file atau direktori yang dibutuhkan.

• Aplikasi gagal terhubung ke database atau layanan lain.

• Proses berhenti akibat keterbatasan memori atau resource.

• Unit systemd memiliki parameter startup yang tidak sesuai.

  Baca JugaLinux Server Load Average Tinggi Padahal Trafik Rendah? Ini Cara Mengeceknya

Pesan yang muncul ketika menjalankan systemctl restart biasanya hanya ringkasan. Detail penyebabnya lebih sering ditemukan pada journal systemd atau log aplikasi.

Langkah pertama: Periksa status service

Gunakan perintah berikut untuk melihat status service yang gagal:

sudo systemctl status nginx --no-pager -l

Pada contoh ini, nginx adalah service yang diperiksa. Ganti dengan nama service yang benar pada server kamu.

Opsi --no-pager menampilkan hasil langsung di terminal, sedangkan -l mencegah baris pesan panjang dipotong.

Perhatikan beberapa bagian berikut:

• Active: menunjukkan kondisi service, misalnya failed, inactive, atau active (running).

• Loaded: menunjukkan apakah unit ditemukan dan bagaimana unit tersebut dimuat.

• Process: dapat menampilkan proses terkait dan kode keluar.

• Main PID: menunjukkan PID proses utama jika tersedia.

• Error message: petunjuk tentang kegagalan menjalankan service.

Contohnya, jika terlihat status=1/FAILURE, artinya proses keluar dengan kode 1. Kode tersebut belum menjelaskan penyebab spesifiknya; kamu perlu membaca pesan aplikasi atau log yang menyertainya.

Jika service ternyata tidak ditemukan, pastikan nama unitnya benar:

systemctl list-unit-files --type=service

Perintah tersebut menampilkan unit service yang tercatat. Nama unit dapat berbeda menurut distribusi, versi paket, atau aplikasi yang digunakan.

Gunakan journalctl untuk menemukan penyebab sebenarnya

Jika output systemctl status belum memberikan jawaban, pemeriksaan berikutnya adalah journal systemd. Di sinilah kamu biasanya dapat menemukan pesan yang menjelaskan mengapa proses berhenti atau gagal dijalankan.

A. Baca log service pada boot saat ini

sudo journalctl -u nginx -b --no-pager

Keterangan:

• -u nginx memfilter log berdasarkan unit service.

• -b membatasi log pada boot sistem saat ini.

• --no-pager menampilkan log langsung di terminal.

Untuk mempersingkat output, gunakan:

sudo journalctl -u nginx -b -n 100 --no-pager

Perintah ini menampilkan maksimal 100 entri log terbaru yang sesuai dengan filter tersebut.

Cari pesan error yang muncul tepat sebelum service dinyatakan gagal. Baris pertama yang terlihat merah atau mengandung kata failed belum tentu akar masalah; bisa jadi itu hanya dampak dari error sebelumnya.

B. Periksa log berdasarkan waktu

Jika kamu mengetahui kapan service mulai bermasalah, batasi pencarian ke rentang waktu tersebut:

Baca JugaCara Mengatasi SSH Connection Refused di VPS: Diagnosis dan Solusi

sudo journalctl -u nginx \--since "30 minutes ago" \--no-pager

Ini berguna ketika log terlalu panjang atau service sudah berulang kali dicoba untuk dijalankan.

C. Periksa log boot sebelumnya

Jika masalah muncul setelah reboot, tetapi log boot saat ini tidak menjelaskan penyebabnya, periksa boot sebelumnya:

sudo journalctl -u nginx -b -1 --no-pager

Opsi -b -1 meminta log dari boot sebelumnya. Log ini hanya tersedia jika masih tersimpan dan dapat diakses.

Jika tidak ada hasil, bukan berarti service tidak pernah gagal. Journal mungkin bersifat sementara, log sudah tidak tersedia, atau nama unit yang digunakan tidak tepat.

Kenali pola error dari hasil log

Setelah mengumpulkan log, cocokkan pesan yang ditemukan dengan pemeriksaan berikut.

Pesan-pesan tersebut menunjukkan arah diagnosis, bukan bukti bahwa penyebabnya sudah pasti.

Periksa konfigurasi service sebelum melakukan restart

Jika log mengarah pada konfigurasi service, periksa konfigurasi yang benar-benar digunakan systemd.

A. Lihat file unit dan override

sudo systemctl cat nginx

Perintah ini menampilkan file unit beserta konfigurasi tambahan atau drop-in override yang terkait. Periksa bagian seperti ExecStart=, ExecStartPre=, User=, Group=, EnvironmentFile=, dan WorkingDirectory= jika ada.

Kesalahan pada path executable, file environment, atau direktori kerja dapat membuat proses gagal dimulai.

Baca JugaCara Mengatasi Disk Full di Ubuntu Server Tanpa Menghapus Data Penting

Jangan langsung mengedit file unit bawaan di /usr/lib/systemd/system/ atau /lib/systemd/system/. Jika memang perlu mengubah konfigurasi systemd, gunakan mekanisme override yang sesuai agar perubahan lebih mudah dikelola.

B. Validasi file unit jika kamu mengubah konfigurasi systemd

Jika kamu memiliki file unit khusus, periksa sintaksnya menggunakan:

sudo systemd-analyze verify /etc/systemd/system/myapp.service

Ganti path tersebut dengan file unit yang sebenarnya. Perintah ini membantu menemukan kesalahan pada unit file dan dependensinya, tetapi tidak membuktikan bahwa aplikasi akan berjalan dengan benar ketika dijalankan.

Jika kamu mengubah unit file, muat ulang konfigurasi systemd:

sudo systemctl daemon-reload

Perintah tersebut meminta systemd membaca ulang konfigurasi unit. Ini berbeda dari systemctl reload nginx, yang meminta aplikasi memuat ulang konfigurasi aplikasinya sendiri.

Setelah itu, jalankan service hanya jika perubahan sudah diperiksa dan aman untuk diterapkan.

Diagnosis berdasarkan jenis service

Tidak semua service menyimpan detail error di tempat yang sama. Jika journal systemd hanya menampilkan pesan umum, lanjutkan ke pemeriksaan aplikasi.

A. Nginx atau Apache gagal start

Periksa konfigurasi Nginx:

sudo nginx -t

Perintah ini memvalidasi konfigurasi Nginx. Jika muncul pesan tentang file konfigurasi atau baris tertentu, perbaiki bagian tersebut terlebih dahulu.

Untuk Apache pada Ubuntu atau Debian:

sudo apache2ctl configtest

Jika hasilnya menunjukkan konfigurasi valid tetapi service masih gagal, periksa apakah port yang dibutuhkan sedang digunakan:

sudo ss -ltnp

Perintah tersebut menampilkan socket TCP yang sedang mendengarkan, beserta informasi proses jika tersedia. Periksa port yang relevan, seperti 80 atau 443, lalu identifikasi service pemilik port tersebut sebelum mengambil tindakan.

B. MySQL atau MariaDB gagal start

Periksa status dan log:

sudo systemctl status mysql --no-pager -lsudo journalctl -u mysql -b -n 100 --no-pager

Pada sebagian sistem, nama unitnya adalah mariadb.service. Gunakan nama unit yang sesuai dengan instalasi kamu.

Jika log menunjukkan masalah konfigurasi, periksa konfigurasi database. Jika menunjukkan kegagalan akses file atau ruang disk, lanjutkan pemeriksaan sesuai pesan tersebut.

Baca JugaVPS Tidak Bisa Diakses Setelah Restart? Ini Cara Diagnosisnya

Jangan menghapus file database, file InnoDB, atau file PID secara sembarangan. Tindakan yang tampak sederhana dapat memperparah kerusakan jika proses database sebenarnya masih berjalan atau sedang melakukan pemulihan.

C. PHP-FPM gagal start

Periksa nama unit PHP-FPM yang tersedia:

systemctl list-unit-files 'php*-fpm.service'

Kemudian, gunakan nama unit yang benar untuk membaca log. Misalnya, pada instalasi yang menggunakan PHP 8.3:

sudo systemctl status php8.3-fpm --no-pager -lsudo journalctl -u php8.3-fpm -b -n 100 --no-pager

Jika pesan error mengarah ke konfigurasi pool, periksa file konfigurasi PHP-FPM yang relevan dan validasi menggunakan executable PHP-FPM yang sesuai dengan versi terpasang.

Jangan menyalin perintah validasi dari versi PHP lain tanpa memeriksa executable yang tersedia.

Jika service terkena Start request repeated too quickly

Pesan ini berarti systemd membatasi percobaan start karena service gagal terlalu sering dalam interval tertentu. Ini biasanya merupakan akibat dari kegagalan sebelumnya, bukan akar masalah yang berdiri sendiri.

Langkah pertama adalah membaca log sebelum batas restart tercapai:

sudo journalctl -u myapp.service -b -n 150 --no-pager

Ganti myapp.service dengan nama unit sebenarnya.

Cari pesan awal yang menunjukkan mengapa aplikasi berhenti. Setelah akar masalah diperbaiki, kamu mungkin perlu mengatur ulang status kegagalan:

sudo systemctl reset-failed myapp.service

Perintah ini mereset status failed dan penghitung pembatasan start. Perintah tersebut tidak memperbaiki penyebab kegagalan.

Jika konfigurasi sudah benar dan aman, coba mulai service kembali:

sudo systemctl start myapp.servicesudo systemctl status myapp.service --no-pager -l

Hindari menaikkan batas restart hanya untuk menyembunyikan masalah. Jika aplikasi terus crash, pengaturan tersebut dapat membuat kegagalan berulang tanpa menyelesaikan akar penyebabnya.

Verifikasi hasil perbaikan

Setelah perubahan dilakukan, pastikan service benar-benar berjalan, bukan sekadar berhasil menerima perintah start.

Jalankan:

sudo systemctl is-active nginxsudo systemctl status nginx --no-pager -l

Jika service menyediakan endpoint HTTP, lakukan pengujian tambahan yang sesuai. Untuk Nginx yang melayani HTTP lokal, misalnya:

curl -I --connect-timeout 5 http://127.0.0.1/

Respons HTTP menunjukkan bahwa endpoint merespons, tetapi belum tentu membuktikan semua fungsi website normal. Jika website memakai virtual host, HTTPS, reverse proxy, atau aplikasi backend, lakukan pengujian yang sesuai dengan arsitektur tersebut.

Periksa kembali log terbaru:

sudo journalctl -u nginx --since "5 minutes ago" --no-pager

Hasil yang diharapkan adalah service berada dalam status aktif yang sesuai, tidak langsung berhenti lagi, dan fungsi yang bergantung padanya dapat digunakan. Ini merupakan kriteria verifikasi yang perlu kamu uji di server, bukan klaim bahwa masalah sudah diperbaiki tanpa hasil pengujian nyata.

Tips mencegah service Linux gagal berulang kali

• Simpan salinan konfigurasi sebelum mengubah file aplikasi atau unit systemd.

• Jalankan validator konfigurasi sebelum restart atau reload jika aplikasi menyediakan fitur tersebut.

• Pantau penggunaan RAM, disk, dan inode jika service sering berhenti tanpa sebab yang jelas.

• Periksa log sebelum menjalankan restart berulang kali.

• Gunakan override systemd untuk penyesuaian unit yang diperlukan.

• Hindari perubahan permission secara rekursif tanpa mengetahui user dan akses yang dibutuhkan aplikasi.

• Pastikan dependensi seperti database, mount point, dan layanan jaringan tersedia sesuai kebutuhan aplikasi.

• Catat perubahan konfigurasi beserta waktu pelaksanaannya agar lebih mudah menghubungkan perubahan dengan error yang muncul.

FAQs

1. Apa perintah paling cepat untuk mencari penyebab service failed?

Gunakan:

sudo systemctl status nama-service --no-pager -lsudo journalctl -u nama-service -b -n 100 --no-pager

Perintah pertama menunjukkan status service, sedangkan perintah kedua membantu menemukan pesan error yang lebih terperinci.

2. Mengapa systemctl status hanya menampilkan pesan gagal?

Karena status service berfungsi sebagai ringkasan kondisi dan aktivitas terbaru. Detail error dapat berada di entri journal yang lebih lama atau pada log aplikasi itu sendiri.

3. Apakah systemctl restart dapat memperbaiki service yang failed?

Bisa jika masalahnya bersifat sementara dan sudah tidak terjadi. Namun, jika penyebabnya adalah konfigurasi salah, port bentrok, atau file yang hilang, restart biasanya hanya mengulangi kegagalan yang sama.

4. Apakah systemctl reset-failed memperbaiki service?

Tidak. Perintah tersebut mengatur ulang status kegagalan dan penghitung pembatasan start. Penyebab aplikasi gagal tetap harus diperiksa dan diperbaiki secara terpisah.

5. Bagaimana jika log service kosong?

Pastikan nama unit benar, gunakan hak akses yang sesuai, dan periksa apakah journal menyimpan log dari periode yang dibutuhkan. Jika aplikasi mencatat log ke file tersendiri, periksa lokasi log tersebut berdasarkan konfigurasi aplikasinya.

Penutup

Ketika menemukan systemctl service failed, mulailah dari status service, lanjutkan ke journalctl, kemudian periksa konfigurasi, dependensi, port, permission, atau resource sesuai pesan yang ditemukan.

Kunci troubleshooting bukan menjalankan lebih banyak perintah restart, melainkan menemukan bukti yang menjelaskan mengapa service gagal. Dengan diagnosis yang terarah, kamu dapat mengurangi perubahan yang tidak perlu dan menghindari gangguan tambahan pada VPS atau server produksi.