Troubleshooting Server

Bab 42 ditutup dengan satu pengakuan jujur: pipeline deploy demo-node yang baru saja kita bangun belum menyertakan health check otomatis. Step terakhir workflow GitHub Actions, "Kirim rilis lewat SSH", dianggap berhasil begitu tar selesai diekstrak dan systemctl restart selesai dieksekusi, bukan begitu aplikasi benar-benar terbukti tetap hidup setelahnya. Skenario yang disinggung di penutup bab itu sekarang benar-benar terjadi. Tab Actions pada repository demo-node menampilkan centang hijau di semua step, tetapi User yang mencoba membuka http://192.168.1.40:3000 mendapati koneksinya ditolak. Sysadmin yang menerima laporan ini belum tahu apakah masalahnya ada di kode aplikasi, di service systemd, di jaringan, atau bahkan di server database yang dipakai aplikasi lain di infrastruktur yang sama.

Momen seperti inilah inti dari troubleshooting, yaitu proses menemukan penyebab pasti sebuah masalah lalu memperbaikinya, dibedakan tegas dari sekadar mengubah konfigurasi satu per satu sambil berharap salah satunya kebetulan berhasil. Seluruh bab sebelumnya membekali kita dengan tool dan layanan spesifik, mulai dari jaringan di Bagian III, layanan web di Bagian IV, database di Bagian V, sampai otomasi di Bagian IX. Bab ini tidak memperkenalkan tool baru. Bab ini menyatukan semuanya lewat cara berpikir yang sama, dipakai berulang-ulang oleh Sysadmin berpengalaman setiap kali sesuatu di produksi berhenti bekerja sebagaimana mestinya.

Pembahasan dimulai dari kerangka kerja metodologis supaya proses mencari akar masalah tidak bergantung pada firasat, dilanjutkan peta lengkap log yang jadi sumber bukti utama, lalu masuk ke empat skenario paling sering ditemui di lapangan: service yang gagal start, disk yang tiba-tiba penuh, koneksi jaringan atau DNS yang bermasalah, dan database yang tidak bisa diakses. Bab ditutup dengan cara mencari bantuan secara efektif untuk kasus yang benar-benar di luar jangkauan pengetahuan kita sendiri.

43.1 Metodologi Troubleshooting Sistematis di Lingkungan Produksi

43.1.1 Kenapa Menebak Menjadi Kebiasaan Paling Mahal di Server Produksi

Reaksi paling umum saat sebuah service tiba-tiba bermasalah adalah mengubah beberapa hal sekaligus secara berurutan cepat: restart service, lalu restart server, lalu ubah satu baris konfigurasi yang terlihat mencurigakan, semua dalam hitungan menit karena tekanan ingin masalah segera selesai. Cara ini kadang kebetulan berhasil, tetapi menyisakan pertanyaan yang jauh lebih berbahaya daripada masalah awalnya sendiri, yaitu perubahan mana sebenarnya yang benar-benar memperbaiki keadaan. Tanpa jawaban pasti, masalah yang sama berpotensi muncul lagi di waktu yang tidak terduga, dan Sysadmin akan mengulang seluruh proses tebak-tebakan itu dari awal karena tidak pernah benar-benar tahu akar masalahnya.

Di lapangan, kebiasaan menebak ini justru memburuk tepat saat paling berbahaya, yaitu ketika insiden terjadi di luar jam kerja dan tekanan untuk cepat selesai jauh lebih besar dibanding saat suasana tenang. Rasa panik mendorong Sysadmin mengubah banyak variabel sekaligus, sementara kebutuhan sebenarnya justru sebaliknya: pendekatan yang lebih tenang dan lebih terstruktur, bukan lebih tergesa. Bagian ini menawarkan kerangka kerja lima langkah yang menjaga proses tetap sistematis, sekalipun jam menunjukkan pukul dua pagi.

43.1.2 Kerangka Kerja Lima Langkah: Definisikan, Kumpulkan Data, Berhipotesis, Uji, Verifikasi

Kerangka kerja berikut bukan prosedur kaku yang harus diikuti kata demi kata, melainkan urutan berpikir yang mencegah dua kesalahan paling umum dalam troubleshooting: melompat ke kesimpulan sebelum data cukup, dan mengubah banyak hal sekaligus sehingga penyebab sebenarnya tidak pernah benar-benar diketahui.

1. Definisikan gejala secara presisi. "Aplikasi error" bukan definisi yang bisa ditelusuri. "User tidak bisa membuka http://192.168.1.40:3000, koneksi ditolak, mulai terjadi setelah deploy pukul 23.40" jauh lebih bisa ditindaklanjuti karena sudah menyebutkan target, gejala persis, dan waktu mulai kejadian.
2. Kumpulkan data sebelum berteori. Baca log dan status service dulu (Bagian 43.2), baru bentuk dugaan. Kebiasaan yang terbalik, yaitu menduga penyebabnya lebih dulu baru mencari log yang mendukung dugaan itu, cenderung membuat Sysadmin mengabaikan bukti yang sebenarnya mengarah ke penyebab lain.
3. Bentuk satu hipotesis, lalu uji. Hipotesis yang baik bisa dijawab benar atau salah lewat satu pengecekan konkret, misalnya "service gagal start karena port 3000 sudah dipakai proses lain" bisa langsung diuji lewat ss -tulnp, bukan "sepertinya ada yang salah di server".
4. Ubah satu variabel dalam satu waktu, catat setiap perubahan. Godaan terbesar saat tertekan adalah mengubah beberapa konfigurasi sekaligus. Menahan godaan itu adalah satu-satunya cara memastikan perbaikan yang berhasil benar-benar bisa diulang kembali di masa depan, dan bukan kebetulan.
5. Verifikasi perbaikan, lalu dokumentasikan akar masalahnya. Service kembali menyala bukan akhir dari proses. Catat penyebab sesungguhnya (root cause) dan langkah pencegahan supaya kejadian yang sama tidak lolos dua kali, persis seperti evaluasi yang sudah disinggung di Bagian 42.5.3 soal pentingnya health check otomatis yang belum sempat kita bangun.

Sebelum masuk ke log secara mendalam, satu kebiasaan cepat yang layak dilakukan di awal insiden adalah memeriksa dari luar ke dalam: apakah server bisa dijangkau lewat jaringan, apakah service-nya sendiri hidup, baru kemudian membaca isi log aplikasi. Urutan pemeriksaan cepat ini langsung dipraktikkan pada insiden demo-node yang membuka bab ini.

ping -c 3 192.168.1.40
curl -v http://192.168.1.40:3000
ssh [email protected] "systemctl status demo-node.service"

ping yang berhasil menandakan jaringan dasar dan host masih hidup, sehingga masalah kemungkinan besar bukan di layer jaringan (Bagian 43.3.3). curl -v yang gagal dengan Connection refused pada percobaan ini berarti tidak ada proses yang mendengarkan di port 3000, mengarahkan dugaan langsung ke service-nya sendiri (Bagian 43.3.1), berbeda dari curl yang gagal dengan timeout tanpa pesan tolakan sama sekali, yang biasanya justru menunjuk ke firewall atau routing.

43.2 Log Penting sebagai Sumber Kebenaran Pertama

43.2.1 journalctl -b: Membaca Log Sejak Boot Terakhir

Bagian 39.1 sudah membahas journalctl secara mendalam untuk memfilter berdasarkan unit, waktu, dan priority. Satu flag yang belum banyak disinggung namun sangat berguna saat troubleshooting pasca-reboot atau pasca-crash adalah -b, yang membatasi output hanya pada log sejak boot tertentu.

journalctl -b

Tanpa argumen tambahan, -b menampilkan log sejak boot yang sedang berjalan sekarang. Argumen negatif menunjuk boot-boot sebelumnya, sangat berguna ketika server sempat reboot sendiri tanpa sepengetahuan Sysadmin, sebuah gejala yang sering menandakan masalah hardware, kehabisan memory yang memicu OOM killer, atau kernel panic.

journalctl --list-boots
journalctl -b -1
journalctl -b -1 -p err

journalctl --list-boots menampilkan daftar seluruh boot yang masih tersimpan di journal, lengkap dengan boot ID dan rentang waktunya. journalctl -b -1 membuka log boot sebelum yang sekarang, dan menambah -p err mempersempitnya hanya ke pesan dengan tingkat keparahan error ke atas, langkah pertama yang wajar ketika dicurigai server sempat reboot tidak wajar semalam.

43.2.2 Peta /var/log/: Log Sistem vs Log Aplikasi Pihak Ketiga

Bagian 39.1.1 sudah menjelaskan bahwa systemd-journald menangkap log dari seluruh service systemd secara terpusat. Namun tidak semua software menulis log lewat journald saja. Sebagian tool populer, terutama yang lahir sebelum systemd menjadi standar atau yang sengaja dirancang lintas platform, tetap menulis log plaintext miliknya sendiri ke /var/log/, terlepas dari journald. Memahami peta ini penting supaya waktu insiden tidak habis mencari log di tempat yang salah.

Pola paling aman ketika belum yakin sebuah service menulis log ke mana adalah memeriksa dulu lewat journalctl -u nama.service. Jika hasilnya kosong atau hanya berisi pesan start/stop tanpa detail, barulah menelusuri kemungkinan file log terpisah di /var/log/, umumnya berada di subdirektori bernama sama dengan paketnya.

43.2.3 Menyaring Log Secara Cepat Saat Insiden Sedang Berjalan

Waktu adalah sumber daya paling terbatas saat insiden sedang berlangsung. Kombinasi filter berikut mempercepat proses menemukan baris yang relevan dibanding membaca log secara berurutan dari awal.

journalctl -u demo-node.service --since "-15min" --no-pager
journalctl -u demo-node.service -u nginx.service --since "-15min"
journalctl -u demo-node.service -p err -b

--since "-15min" mempersempit log hanya ke 15 menit terakhir, jauh lebih relevan saat menelusuri insiden yang baru saja terjadi dibanding membaca seluruh riwayat sejak boot. Menyebut -u lebih dari satu kali, seperti baris kedua di atas, menggabungkan log dua service berbeda dalam satu urutan waktu yang sama, teknik yang sangat membantu ketika ingin melihat urutan kejadian lintas layer, misalnya request masuk ke Nginx tepat sebelum aplikasi backend di baliknya mencatat error.

Teknik yang tidak kalah penting adalah mengorelasikan waktu antar-sumber data. Pada insiden demo-node di pembuka bab ini, nama direktori rilis di /opt/demo-node/releases/ sendiri sudah berupa timestamp YYYYMMDDHHMMSS sejak Bagian 42.3.3, sehingga membandingkan timestamp rilis terbaru dengan timestamp baris pertama error di journal langsung menunjukkan apakah error tersebut memang muncul tepat setelah deploy, atau sudah ada sejak sebelumnya karena sebab lain.

ls -1 /opt/demo-node/releases/ | tail -n1
journalctl -u demo-node.service --since "2026-08-28 23:40:00"

43.3 Skenario Umum Troubleshooting Server Produksi

43.3.1 Service Gagal Start: Studi Kasus demo-node di app01

Bagian ini menyelesaikan insiden yang membuka bab: curl ke demo-node menolak koneksi tepat setelah deploy terbaru, padahal pipeline CI/CD di Bagian 42.4.2 melaporkan sukses penuh.

Langkah Praktik

1. Login ke app01, lalu periksa status service. Baris Active adalah yang paling penting dibaca lebih dulu.

   ssh [email protected]
   sudo systemctl status demo-node.service

2. Output menunjukkan status berulang kali berpindah antara activating (auto-restart) dan failed, dengan baris Main PID menyebut code=exited, status=1/FAILURE. Status 1/FAILURE menandakan proses Node.js keluar sendiri karena exception yang tidak tertangani, berbeda dari 203/EXEC yang berarti path binary di ExecStart salah, atau 127 yang berarti perintahnya tidak ditemukan sama sekali.
3. Baca detail exception-nya lewat journal, dibatasi hanya baris terbaru supaya tidak tenggelam dalam pengulangan restart yang sama.

   journalctl -u demo-node.service -n 30 --no-pager

4. Log menunjukkan baris seperti berikut, berulang setiap kali systemd mencoba restart.

   SyntaxError: Unexpected token ')'
       at wrapSafe (node:internal/modules/cjs/loader:1378:18)
       at Module._compile (node:internal/modules/cjs/loader:1428:20)

5. Ini adalah bug pada kode yang baru saja di-push, lolos dari tahap test CI karena node --test pada Bagian 42.2.3 hanya menguji fungsi buildResponseText, sementara SyntaxError ini berasal dari baris lain yang tidak tersentuh test tersebut. Daripada mencoba menambal kode langsung di server produksi, gunakan rollback.sh yang sudah disiapkan tepat untuk situasi ini di Bagian 42.5.2.

   sudo /opt/demo-node/rollback.sh

Verifikasi dan Troubleshooting

• Pastikan service kembali stabil dan aplikasi merespons normal.

  sudo systemctl status demo-node.service
  curl http://192.168.1.40:3000

  Baris Active: active (running) yang tidak lagi berpindah status dalam beberapa menit menandakan rollback berhasil.
• Unit tanpa StartLimitIntervalSec atau StartLimitBurst eksplisit, seperti demo-node.service sejak Bagian 15.6.2, mewarisi nilai default systemd yaitu maksimum lima kali percobaan start dalam sepuluh detik. Jika batas ini terlampaui, systemd berhenti mencoba lagi dan status berubah permanen ke failed dengan pesan start-limit-hit, situasi yang mengharuskan sudo systemctl reset-failed demo-node.service dijalankan lebih dulu sebelum service bisa di-start ulang, sekalipun penyebab utamanya sudah diperbaiki.
• Dua penyebab lain yang sama umum untuk gejala "service gagal start" meski tidak terjadi pada insiden ini tetap layak diperiksa lebih dulu di kasus serupa. Port yang sudah dipakai proses lain menghasilkan Error: listen EADDRINUSE pada log, diperiksa lewat sudo ss -tulnp | grep 3000. Permission yang salah pada file aplikasi menghasilkan EACCES, umumnya karena rilis baru ter-extract dengan pemilik yang keliru, diperiksa lewat ls -l /opt/demo-node/current dan dibandingkan dengan user nodeapp yang seharusnya menjalankan service sejak Bagian 15.6.2.
• Langkah lanjutan yang jujur perlu disebut di sini adalah memperbaiki akar masalah sesuai kerangka kerja Bagian 43.1.2 langkah kelima: menambahkan test yang mencakup skenario yang gagal ini di repository demo-node, dan mempertimbangkan health check otomatis sebelum symlink dipindahkan seperti sudah disinggung di Bagian 42.5.3, supaya rollback berikutnya terjadi otomatis tanpa menunggu laporan User.

43.3.2 Disk Penuh di Server Produksi

Disk yang penuh tidak seperti CPU tinggi yang biasanya pulih sendiri begitu beban berkurang. Disk penuh cenderung memburuk terus sampai ditangani manual, dan begitu benar-benar habis, banyak service berhenti bekerja dengan gejala yang membingungkan karena tidak bisa lagi menulis log atau file sementara miliknya sendiri. Skenario di bagian ini memeriksa server utama (192.168.1.10) setelah dashboard Netdata pada Bagian 38.2.3 menunjukkan pemakaian disk sudah di atas 90 persen.

Langkah Praktik

1. Konfirmasi dulu filesystem mana yang benar-benar penuh, karena satu server bisa punya beberapa mount point terpisah dengan kapasitas berbeda-beda.

   df -h

2. Setelah tahu mount point yang bermasalah, misalnya /, telusuri direktori mana yang paling banyak memakan ruang, dimulai dari /var karena di situlah sebagian besar data yang terus bertumbuh biasanya tersimpan.

   sudo du -sh /var/* 2>/dev/null | sort -rh | head -10

3. Empat penyebab paling umum ditemukan lewat perintah di atas, urut dari yang paling sering ditemui di lapangan, adalah cache paket APT, kernel lama yang menumpuk, image dan build cache Docker, serta log aplikasi kustom yang belum masuk aturan logrotate. Bersihkan cache APT lebih dulu karena paling aman dan paling cepat memberi ruang bernapas.

   sudo apt clean

4. Periksa apakah kernel lama ikut menumpuk di /boot, partisi yang sering kali sengaja dibuat kecil sehingga jadi salah satu titik pertama yang penuh.

   df -h /boot
   dpkg -l 'linux-image-*' | grep ^ii
   uname -r

5. Hapus kernel lama yang tidak lagi dipakai lewat autoremove, jauh lebih aman dibanding menghapus manual satu per satu dengan dpkg -r karena APT tahu paket mana yang aman dibuang tanpa merusak dependency.

   sudo apt autoremove --purge

6. Jika server ini juga menjalankan Docker sejak Bab 26 atau 27, periksa berapa banyak ruang yang dipakai image, container berhenti, dan build cache yang sudah tidak terpakai.

   docker system df

7. Bersihkan resource Docker yang menganggur. Tambahkan -a hanya jika benar-benar yakin image yang sedang tidak dipakai container mana pun juga aman dihapus.

   docker system prune -a

8. Penyebab keempat, log aplikasi kustom yang belum masuk aturan logrotate, paling sering luput karena tidak terlihat lewat du -sh /var/* di langkah 2 jika log tersebut ditulis ke subdirektori yang jarang dilihat. Periksa langsung file log berukuran besar di seluruh /var/log/, bukan hanya di direktori yang sudah dicurigai.

   sudo find /var/log -type f -size +200M -exec ls -lh {} \;

9. File sebesar /var/log/remote/*.log hasil forwarding sejak Bagian 39.2 adalah contoh paling relevan di infrastruktur ini, karena log tersebut baru mendapat aturan rotasi lewat konfigurasi kustom di Bagian 39.3.2. Jika file serupa ditemukan tanpa aturan rotasi apa pun, periksa dulu apakah entrinya memang ada di /etc/logrotate.d/ sebelum menambah yang baru.

   ls /etc/logrotate.d/
   sudo logrotate -d /etc/logrotate.d/remote-logs

   Flag -d menjalankan logrotate dalam mode dry run, menampilkan apa yang akan dilakukan tanpa benar-benar memutar file log, cara aman memastikan aturan yang sudah ada memang berjalan sesuai jadwal sebelum menyalahkan konfigurasinya.

Verifikasi dan Troubleshooting

• Ulangi df -h setelah setiap langkah pembersihan untuk melihat dampaknya secara bertahap, alih-alih menjalankan semua langkah sekaligus lalu baru memeriksa hasilnya, sejalan dengan prinsip "ubah satu variabel dalam satu waktu" di Bagian 43.1.2.
• Jangan pernah menghapus kernel yang sedang berjalan. Bandingkan selalu keluaran uname -r dengan daftar paket linux-image sebelum menghapus apa pun secara manual. apt autoremove pada langkah 5 sudah otomatis mengecualikan kernel yang sedang aktif dan setidaknya satu kernel sebelumnya sebagai cadangan, tetapi kebiasaan memeriksa manual tetap penting sebelum mengetik perintah dpkg -r sendiri.
• docker system prune -a bersifat destruktif terhadap image yang belum ditandai dipakai container mana pun. Di server dengan pipeline CI/CD seperti app01 pada Bab 42, ini berarti build berikutnya perlu mengunduh ulang base image dari registry, memperlambat deploy pertama pasca-pembersihan, konsekuensi yang wajar diterima demi ruang disk tetapi tetap perlu disampaikan jujur ke tim sebelum dijalankan di jam sibuk.
• Jika seluruh langkah pembersihan di atas sudah dilakukan dan disk tetap mendekati penuh karena kebutuhan aplikasi memang bertumbuh wajar, solusi yang tepat bukan terus-menerus membersihkan, melainkan menambah kapasitas. Volume berbasis LVM yang sudah dibahas di Bagian 7.2 bisa diperluas tanpa downtime selama volume group masih punya ruang tersisa, jauh lebih praktis dibanding migrasi data ke disk baru.

43.3.3 Koneksi Jaringan dan DNS Bermasalah

Masalah jaringan sering menyesatkan karena gejalanya di sisi client terlihat identik meski penyebabnya bisa berasal dari layer yang sangat berbeda, mulai dari kabel putus, IP salah, firewall memblokir, sampai DNS yang tidak bisa menerjemahkan nama menjadi alamat. Bagian ini membahas dua skenario nyata: koneksi yang tiba-tiba ditolak akibat kebiasaan sendiri, dan resolusi DNS yang gagal.

Langkah Praktik

1. Skenario pertama, Sysadmin sedang terburu-buru mengetik ulang password SSH ke app01 beberapa kali karena salah ketik, lalu koneksi berikutnya tiba-tiba timeout total, bahkan setelah password diketik benar. Uji dulu apakah host masih hidup di layer jaringan paling dasar.

   ping -c 3 192.168.1.40

2. ping berhasil, artinya host hidup dan ICMP tidak diblokir, tetapi SSH tetap gagal. Ini menunjukkan masalah spesifik di port 22, bukan masalah routing atau host yang mati. Uji koneksi ke port tersebut secara terpisah dari ping.

   nc -zv 192.168.1.40 22

3. Karena percobaan login berkali-kali gagal itulah yang paling mencurigakan, periksa status jail SSH milik Fail2ban dari server lain yang masih bisa terhubung ke app01, misalnya lewat akses console fallback pada Bagian 3.4 atau dari server utama yang IP-nya belum terblokir.

   sudo fail2ban-client status sshd

4. Jika IP kita sendiri muncul di daftar Banned IP list, itulah akar masalahnya: Fail2ban sejak Bab 32 memang dirancang memblokir IP mana pun setelah beberapa kali percobaan login gagal dalam rentang waktu tertentu, tanpa memandang apakah IP itu Attacker sungguhan atau Sysadmin sendiri yang sedang apes salah ketik. Hapus ban ini dengan perintah yang sama seperti sudah dipraktikkan di Bagian 32.5.

   sudo fail2ban-client set sshd unbanip 192.168.1.40

   Ganti nilai IP pada perintah ini dengan IP milik komputer kerja Sysadmin sendiri, bukan IP app01.
5. Skenario kedua, aplikasi di server lain gagal mengunduh dependency dari internet dengan pesan menyinggung kegagalan resolusi nama domain. Uji dulu resolusi DNS terhadap server DNS internal yang sudah dibangun di Bab 9.

   dig @192.168.1.10 registry.npmjs.org +short

6. Jika perintah di atas tidak mengembalikan alamat apa pun, periksa apakah BIND9 di server tersebut masih berjalan, lalu periksa apakah konfigurasi allow-recursion pada Bagian 9.4 memang mengizinkan query rekursif dari subnet asal permintaan ini.

   sudo systemctl status bind9.service
   sudo journalctl -u bind9.service -n 30 --no-pager

7. Periksa juga sisi client, memastikan resolver yang benar-benar dipakai sistem memang menunjuk ke server DNS internal, bukan tertinggal ke resolver lama atau default ISP.

   resolvectl status

Verifikasi dan Troubleshooting

• Setelah unban, uji ulang SSH secara normal, dan pastikan tidak salah ketik password lagi dalam waktu dekat karena jail yang sama akan langsung memblokir ulang begitu ambang batas tercapai lagi.

  ssh [email protected]

• Kejadian salah ketik password berulang yang berujung self-lockout ini jauh lebih sering terjadi daripada kelihatannya, terutama pada script otomasi yang menyimpan password lama setelah credential diganti. Praktik yang lebih tahan terhadap masalah ini adalah beralih sepenuhnya ke autentikasi berbasis key seperti sudah direkomendasikan sejak Bagian 3.2.2, karena percobaan koneksi dengan key yang salah ditolak seketika tanpa retry berulang yang memicu jail Fail2ban.
• Jika dig pada langkah 5 justru mengembalikan jawaban SERVFAIL, bukan kosong, itu biasanya menunjuk ke masalah di zone file itu sendiri, misalnya forwarder ke DNS publik yang salah dikonfigurasi atau tidak bisa dijangkau, berbeda dari dig yang timeout total, yang lebih mengarah ke service BIND9 yang mati atau port 53 yang diblokir firewall.
• Untuk domain internal (bukan domain publik seperti pada langkah 5), tambahkan kecurigaan pada serial number zone file. Perubahan record pada zone Bagian 9.2.1 yang lupa menaikkan serial tidak akan pernah terlihat oleh secondary DNS server, karena mekanisme replikasi DNS memang mengandalkan angka serial untuk tahu ada perubahan baru, bukan mengecek isi file secara langsung.

43.3.4 Database Tidak Bisa Diakses

Developer melaporkan aplikasi webnya gagal terhubung ke database PostgreSQL di 192.168.1.20 yang sudah dikonfigurasi sejak Bagian 18.3. Pesan error yang dilaporkan sangat menentukan arah investigasi, karena tiga jenis pesan error yang berbeda menunjuk ke tiga layer masalah yang sama sekali berbeda: connection refused berarti tidak ada yang mendengarkan di port tujuan, timeout tanpa penolakan berarti ada yang memblokir diam-diam di tengah jalan, dan pesan yang menyebut password atau host not allowed berarti koneksi jaringannya sendiri sudah sampai, hanya saja ditolak di layer autentikasi PostgreSQL.

Langkah Praktik

1. Minta Developer menyalin pesan error persis, bukan parafrase. Pada kasus ini pesannya adalah psql: error: connection to server at "192.168.1.20", port 5432 failed: Connection refused, yang langsung mengarahkan dugaan ke layer jaringan atau service, bukan autentikasi.
2. Login ke server database, lalu periksa apakah service PostgreSQL benar-benar berjalan.

   ssh [email protected]
   sudo systemctl status postgresql
   pg_isready

3. Jika service ternyata aktif normal, connection refused dari luar biasanya berarti PostgreSQL hanya mendengarkan di alamat loopback, belum dibuka untuk koneksi jaringan seperti yang seharusnya sudah diatur di Bagian 18.4.1. Periksa alamat yang benar-benar didengarkan saat ini.

   sudo ss -tulnp | grep 5432

4. Bandingkan hasilnya dengan isi postgresql.conf. Alamat yang tertera hanya 127.0.0.1:5432 tanpa IP server yang sesungguhnya menandakan baris listen_addresses belum diubah atau berubah kembali ke default setelah upgrade PostgreSQL.

   sudo grep listen_addresses /etc/postgresql/*/main/postgresql.conf

5. Jika listen_addresses sudah benar tetapi koneksi tetap ditolak dari IP tertentu, periksa pg_hba.conf, tempat aturan otorisasi per host benar-benar ditentukan terpisah dari alamat yang didengarkan.

   sudo cat /etc/postgresql/*/main/pg_hba.conf

   PostgreSQL mengevaluasi baris pg_hba.conf dari atas ke bawah dan berhenti di baris pertama yang cocok, sehingga urutan baris sama pentingnya dengan isinya sendiri. Baris yang mengizinkan subnet lama tetapi belum diperbarui setelah ada server aplikasi baru dengan IP di luar subnet itu adalah penyebab paling umum ditemukan pada langkah ini.
6. Terakhir, pastikan firewall di server database benar-benar mengizinkan port 5432 dari IP yang bersangkutan, mengikuti pola yang sama seperti aturan UFW untuk service lain sejak Bab 31.

   sudo ufw status numbered

Verifikasi dan Troubleshooting

• Setelah perbaikan diterapkan pada salah satu dari listen_addresses, pg_hba.conf, atau rule firewall, minta Developer mengulang percobaan koneksi yang sama persis seperti Bagian 18.4.2.

  psql -h 192.168.1.20 -U webapp_user -d webapp_db

• Perubahan pada postgresql.conf maupun pg_hba.conf membutuhkan reload agar berlaku, tanpa perlu restart penuh yang memutus koneksi yang sedang aktif.

  sudo systemctl reload postgresql

• Jika pesan errornya sejak awal bukan connection refused melainkan FATAL: sorry, too many clients already, akar masalahnya sama sekali berbeda dari seluruh langkah di atas: jumlah koneksi sudah mencapai batas max_connections. Periksa lewat query berikut, dan curigai kebocoran koneksi di sisi aplikasi (koneksi yang dibuka tapi tidak pernah ditutup) sebagai penyebab paling umum, bukan traffic yang benar-benar setinggi itu.

  SELECT count(*) FROM pg_stat_activity;
  SHOW max_connections;

• Satu kemungkinan lain yang jujur perlu diperiksa lebih dulu sebelum menuduh konfigurasi jaringan adalah disk penuh di server database itu sendiri, sesuai Bagian 43.3.2. PostgreSQL yang tidak bisa lagi menulis write-ahead log karena disk habis akan menolak koneksi baru dengan pesan yang kadang membingungkan dan tidak secara eksplisit menyebut kata "disk", sehingga df -h di server database tetap layak jadi salah satu pengecekan paling awal, bukan paling akhir.

43.4 Mencari Bantuan Secara Efektif

43.4.1 Menyusun Pertanyaan yang Bisa Dijawab Orang Lain

Sehebat apa pun kerangka kerja di Bagian 43.1, ada kalanya sebuah masalah benar-benar di luar pengalaman kita sendiri, dan bertanya ke komunitas atau mencari referensi eksternal jadi langkah yang wajar, bukan tanda kegagalan. Yang membedakan pertanyaan yang cepat dijawab dari pertanyaan yang dibiarkan tanpa respons selama berhari-hari adalah seberapa lengkap dan presisi informasi yang disertakan sejak awal.

Pertanyaan seperti "server saya error, tolong bantu" nyaris mustahil dijawab siapa pun karena tidak menyebut apa pun yang bisa ditindaklanjuti. Bandingkan dengan pertanyaan yang menyertakan komponen berikut, pola yang sama persis dipakai komunitas open source mana pun saat meminta pelapor bug melengkapi laporannya.

• Versi OS dan versi software yang relevan, diambil dari perintah yang bisa langsung dijalankan dan disalin hasilnya, bukan diketik ulang dari ingatan.

  cat /etc/os-release
  dpkg -l | grep nginx

• Perintah persis yang dijalankan, disalin apa adanya, bukan diparafrasekan.
• Pesan error lengkap, disalin dari terminal, bukan dirangkum dengan kata-kata sendiri yang berpotensi menghilangkan detail penting seperti nomor baris atau kode error.
• Potongan log yang relevan dari sumber yang sudah dipetakan di Bagian 43.2.2, dipangkas secukupnya agar tidak membanjiri pembaca dengan baris yang tidak relevan.
• Apa saja yang sudah dicoba, dan hasilnya masing-masing, supaya orang yang membantu tidak menyarankan langkah yang sudah pasti gagal diulang.

Satu kebiasaan yang tidak kalah penting sebelum menempel log atau file konfigurasi ke forum publik adalah menyamarkan data sensitif lebih dulu, seperti password, IP publik asli, atau nama domain internal perusahaan. Baris konfigurasi yang tampak tidak berbahaya sekalipun, misalnya isi pg_hba.conf lengkap, tetap bisa membocorkan skema jaringan internal ke Attacker yang kebetulan membaca forum yang sama.

43.4.2 Sumber Tepercaya: Ask Ubuntu, Server Fault, dan Dokumentasi Resmi

Tidak semua sumber bantuan online kredibel setara, dan sebelum bertanya langsung ke manusia, satu kebiasaan yang jauh lebih cepat dan hampir selalu layak dicoba lebih dulu adalah mencari pesan error persis (disertakan tanda kutip agar mesin pencari tidak memecahnya jadi kata terpisah), karena kemungkinan besar Sysadmin lain sudah pernah menemukan dan mendiskusikan masalah yang sama persis.

Man page tetap layak disebut sebagai sumber pertama yang paling praktis saat insiden sedang berlangsung, karena selalu tersedia secara lokal tanpa bergantung koneksi internet yang mungkin justru jadi bagian dari masalah yang sedang ditelusuri.

man systemctl
man pg_hba.conf

Bab 44 membahas lebih lengkap komunitas dan sumber belajar lanjutan di luar troubleshooting harian, termasuk Discourse resmi Ubuntu Server dan komunitas seperti r/linuxadmin, sebagai bagian dari rekap keseluruhan perjalanan series ini.

Sampai di sini, kita sudah melihat bagaimana seluruh kemampuan yang dibangun sejak Bab 1 saling terhubung tepat pada saat paling dibutuhkan, yaitu ketika sesuatu berhenti bekerja. Kerangka kerja sistematis di Bagian 43.1 mencegah kepanikan berubah jadi tebak-tebakan, peta log di Bagian 43.2 memberi tahu ke mana harus mencari bukti, empat skenario di Bagian 43.3 menunjukkan bagaimana kerangka kerja itu benar-benar dipakai pada masalah nyata, dan Bagian 43.4 memastikan kita tahu kapan dan bagaimana meminta bantuan tanpa membuang waktu orang lain maupun diri sendiri. Troubleshooting bukan kemampuan yang selesai dipelajari dari satu bab, melainkan kebiasaan yang terus terasah setiap kali dipraktikkan di masalah baru. Bab 44 menutup keseluruhan series ini dengan melihat kembali perjalanan yang sudah ditempuh, sekaligus arah yang bisa diambil untuk melangkah lebih jauh sebagai Sysadmin.