Server Linux Bermasalah Jam 2 Pagi? Ini 20 Troubleshooting Production yang Wajib Dikuasai Sysadmin

Pembuka

Ringkasan Cepat

• Fokus dulu ke 4 hal: disk, RAM, CPU/load, dan service status.
• Baca log sebelum restart service agar akar masalah tidak hilang.
• Gunakan urutan cek yang sama saat incident biar keputusan tetap tenang.
• Terapkan quick fix seperlunya, lalu lanjut ke pencegahan.
• Simpan command kunci sebagai checklist operasional tim.

Di production, masalah jarang datang saat kita santai.

Kadang muncul setelah deploy.
Kadang saat traffic sedang tinggi.
Kadang tengah malam.
Kadang tepat setelah semua orang bilang:

“Kayaknya aman.”

Lalu monitoring merah.

Website timeout.
Database lambat.
Disk penuh.
Nginx 502.
Docker restart loop.
SSH tidak bisa masuk.

Sebagai sysadmin, tugas kita bukan sekadar restart service lalu berharap semua normal.

Tugas kita adalah membaca gejala, mempersempit masalah, mencari penyebab, memperbaiki dengan aman, lalu mencegah masalah yang sama terulang.

Artikel ini berisi 20 troubleshooting Linux production yang paling sering ditemui di lapangan.

Formatnya dibuat praktis:

• skenario singkat
• gejala
• cara cek
• penyebab umum
• quick fix
• pencegahan
• takeaway

Karena saat incident terjadi, kamu tidak butuh teori panjang dulu.

Kamu butuh arah.

Toolkit Wajib Saat Troubleshooting

Sebelum masuk ke kasus, siapkan beberapa tools dasar yang sering dipakai saat investigasi.

htop
iotop
iftop
ncdu
mtr
dig
ss
journalctl
tcpdump
lsof

Install di Ubuntu/Debian:

sudo apt update
sudo apt install htop iotop iftop ncdu mtr dnsutils tcpdump lsof -y

Penjelasan singkat:

• htop untuk melihat process CPU/RAM secara interaktif
• iotop untuk melihat process yang berat di disk I/O
• iftop untuk melihat traffic network real-time
• ncdu untuk mencari folder besar dengan lebih nyaman
• mtr untuk troubleshooting packet loss dan route network
• dig untuk cek DNS
• ss untuk melihat port yang listening
• journalctl untuk membaca log systemd
• tcpdump untuk capture traffic network
• lsof untuk melihat file atau port yang sedang dipakai process

⚠️ Catatan: Tidak semua tools harus langsung dipasang di semua server production. Sesuaikan dengan kebijakan perusahaan dan kebutuhan troubleshooting.

Bagian 1 - Masalah Resource

Masalah resource biasanya jadi sumber incident paling klasik.

Server bisa terlihat “hidup”, tapi aplikasi tetap gagal karena disk penuh, RAM habis, CPU mentok, atau I/O tersendat.

Bagian ini fokus ke resource dasar yang wajib dicek dulu sebelum menyalahkan aplikasi.

1. Disk Full Tiba-Tiba

Disk penuh adalah salah satu masalah paling sering terjadi di production.

Biasanya gejalanya tidak selalu langsung jelas. Kadang website error, kadang database gagal write, kadang service tidak mau start.

Yang lebih menyebalkan, sering kali penyebabnya cuma log atau backup lama yang lupa dibersihkan.

Gejala

• website error
• database gagal menulis data
• upload file gagal
• service gagal start
• login SSH terasa lambat
• muncul error:

No space left on device

Cara Cek

Cek penggunaan filesystem:

df -h

Command ini dipakai untuk melihat kapasitas filesystem, berapa yang sudah terpakai, dan mount point mana yang penuh.

Contoh output yang perlu diperhatikan:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   48G  2.0G  96% /

Kalau / sudah 90% ke atas, mulai investigasi.

Cari folder besar:

sudo du -h --max-depth=1 / 2>/dev/null | sort -h

Kalau /var besar, lanjut:

sudo du -h --max-depth=1 /var 2>/dev/null | sort -h

Cari file besar:

sudo find / -type f -size +500M 2>/dev/null

Penyebab Umum

• log membengkak
• backup menumpuk
• file upload terlalu banyak
• Docker image/container tidak pernah dibersihkan
• journal systemd terlalu besar
• cache aplikasi tidak punya retention

Quick Fix

Cek ukuran journal systemd:

journalctl --disk-usage

Bersihkan journal lama:

sudo journalctl --vacuum-time=7d

Atau batasi ukuran journal:

sudo journalctl --vacuum-size=1G

Bersihkan cache package:

sudo apt clean

Kalau server memakai Docker, cek dulu penggunaan disk Docker:

docker system df

Cleanup Docker:

docker system prune

⚠️ PRO TIP: Jangan asal menjalankan docker system prune -a di production. Command itu bisa menghapus image yang tidak sedang dipakai container aktif, tapi mungkin masih dibutuhkan untuk rollback.

Pencegahan

• pasang monitoring disk
• buat alert saat usage >80%
• aktifkan logrotate
• buat retention backup
• audit folder upload dan cache secara berkala

Takeaway

Disk penuh jangan langsung dijawab dengan hapus file random. Cari dulu folder terbesar, pahami fungsinya, baru cleanup dengan aman.

2. Inode Habis

Ini masalah yang sering bikin bingung.

Disk masih kelihatan ada ruang, tapi sistem tetap bilang tidak bisa membuat file baru.

Penyebabnya bisa jadi bukan kapasitas GB yang habis, tapi inode.

Gejala

• disk terlihat belum penuh
• aplikasi gagal membuat file baru
• session tidak bisa dibuat
• upload gagal
• muncul error:

No space left on device

Padahal df -h masih terlihat aman.

Cara Cek

Cek inode:

df -i

Kalau IUse% sudah 100%, artinya inode habis.

Penyebab Umum

• jutaan file kecil
• cache aplikasi tidak dibersihkan
• session PHP menumpuk
• mail queue penuh
• temporary file tidak punya cleanup

Quick Fix

Cari area yang punya banyak file kecil:

sudo find /var -xdev -type f | cut -d "/" -f1-4 | sort | uniq -c | sort -n

Kalau memakai PHP, cek folder session:

sudo du -sh /var/lib/php/sessions 2>/dev/null
sudo find /var/lib/php/sessions -type f | wc -l

Kalau ada cache aplikasi, cek folder cache sesuai stack yang dipakai.

Pencegahan

• atur expiration session
• bersihkan cache berkala
• monitor inode, bukan hanya disk usage
• hindari desain aplikasi yang membuat terlalu banyak file kecil tanpa retention

💡 Insight: Disk masih ada ruang bukan berarti filesystem sehat. Kalau inode habis, sistem tetap tidak bisa membuat file baru.

Takeaway

Saat muncul No space left on device, cek dua hal: df -h untuk kapasitas dan df -i untuk inode.

3. RAM Habis / OOM Killer

Salah satu momen paling membingungkan buat junior sysadmin adalah ketika service mati sendiri.

Tidak ada yang restart.
Tidak ada deploy.
Tidak ada error aplikasi yang jelas.

Tiba-tiba MySQL, PHP-FPM, atau Node.js mati.

Sering kali penyebabnya adalah OOM Killer.

Gejala

• aplikasi restart mendadak
• MySQL/MariaDB mati sendiri
• PHP-FPM berhenti
• container restart
• server freeze beberapa saat
• swap usage tinggi

Cara Cek

Cek memory:

free -h

Perhatikan kolom available, bukan hanya free.

Linux sering memakai RAM untuk cache, jadi free kecil belum tentu masalah.

Cek apakah ada process yang dibunuh kernel:

dmesg -T | grep -i "killed process"

Atau:

journalctl -k | grep -i "out of memory"

Penyebab Umum

• memory leak aplikasi
• terlalu banyak worker process
• query database berat
• traffic naik mendadak
• server terlalu kecil untuk beban aplikasi
• swap tidak ada atau terlalu kecil

Quick Fix

Kalau service mati karena OOM, jalankan kembali service terkait:

sudo systemctl restart service-name

Cek service setelah restart:

sudo systemctl status service-name

Cek process pemakai memory terbesar:

ps aux --sort=-%mem | head

⚠️ PRO TIP: Restart bisa menghidupkan service lagi, tapi tidak menyelesaikan akar masalah. Kalau memory leak atau konfigurasi worker terlalu besar tidak diperbaiki, OOM bisa muncul lagi.

Pencegahan

• monitoring RAM dan swap
• tuning jumlah worker
• batasi memory container
• review query dan cache
• tambah RAM jika beban memang sudah naik
• aktifkan swap dengan ukuran yang wajar

Takeaway

Kalau service mati sendiri tanpa alasan jelas, jangan lupa cek OOM Killer. Kadang kernel yang “menghabisi” process untuk menyelamatkan sistem.

4. CPU 100%

CPU tinggi biasanya langsung terasa.

SSH delay, website lambat, command sederhana terasa berat, dan monitoring mulai teriak.

Tapi CPU 100% tidak selalu berarti server harus langsung direboot.

Cari dulu process yang paling rakus.

Gejala

• server lambat
• SSH terasa delay
• request aplikasi timeout
• load average naik
• fan server fisik berisik, kalau masih pakai bare metal

Cara Cek

Gunakan top:

top

Atau kalau tersedia:

htop

Cari process dengan CPU tertinggi:

ps aux --sort=-%cpu | head

Cek detail process tertentu:

ps -p PID -o pid,ppid,user,%cpu,%mem,cmd

Penyebab Umum

• loop bug aplikasi
• query database berat
• cron job berjalan bersamaan
• proses backup atau compression
• traffic naik
• malware atau crypto miner

Quick Fix

Kalau process jelas bermasalah dan aman dihentikan:

kill PID

Kalau process tidak mau berhenti:

kill -9 PID

🚨 DANGER ZONE: Jangan jadikan kill -9 sebagai kebiasaan pertama. kill -9 memaksa process mati tanpa cleanup normal. Pakai hanya jika benar-benar perlu dan kamu tahu process itu apa.

Pencegahan

• monitoring CPU
• batasi cron overlap
• review job berat
• audit process asing
• optimasi query dan aplikasi

Takeaway

CPU tinggi harus dilacak ke process spesifik. Jangan langsung reboot sebelum tahu siapa pelakunya.

5. Load Average Tinggi

Load average sering disalahpahami.

Angka load tinggi belum tentu CPU 100%. Bisa juga karena process menunggu disk I/O.

Jadi saat load naik, jangan cuma lihat CPU. Cek juga disk dan process yang blocked.

Gejala

• server lambat
• command terasa delay
• aplikasi timeout
• CPU terlihat tidak selalu penuh, tapi load tinggi

Cara Cek

Cek load average:

uptime

Contoh:

load average: 4.50, 3.20, 2.10

Cek jumlah CPU core:

nproc

Load 4 di server 1 core itu berat.

Load 4 di server 8 core bisa saja masih wajar.

Cek I/O:

iostat -xz 1

Kalau iostat belum ada:

sudo apt install sysstat -y

Penyebab Umum

• disk I/O bottleneck
• query database berat
• backup berjalan
• process menunggu storage
• terlalu banyak request bersamaan

Quick Fix

Cek process yang berat:

ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head

Cek disk I/O dengan iotop:

sudo iotop

Pencegahan

• gunakan SSD/NVMe untuk workload berat
• tuning database
• pisahkan backup dari jam sibuk
• monitoring load dan disk I/O
• optimasi query lambat

Takeaway

Load average harus dibaca bersama jumlah CPU core dan kondisi I/O. Angka tinggi bukan diagnosis, tapi sinyal untuk investigasi.

Bagian 2 - Masalah Service, Web Server, dan Database

Setelah resource dicek, langkah berikutnya adalah service.

Banyak incident production sebenarnya berawal dari service mati, config invalid, port bentrok, atau dependency tidak siap.

Bagian ini membahas masalah yang sering muncul di web server, service systemd, SSL, dan database.

6. Nginx 502 Bad Gateway

Error ini timing-nya sering tidak sopan.

Lagi deploy update Laravel.
Traffic sedang ramai.
PM sedang pantau dashboard.

Tiba-tiba:

502 Bad Gateway

Dan semua orang langsung menoleh ke engineer infra.

Gejala

• halaman web menampilkan 502
• Nginx hidup, tapi backend tidak merespons
• aplikasi terasa down walaupun server masih bisa SSH

Cara Cek

Cek Nginx:

sudo systemctl status nginx

Cek PHP-FPM jika aplikasi memakai PHP:

sudo systemctl status php8.3-fpm

Versi PHP bisa berbeda, misalnya php8.1-fpm, php8.2-fpm, atau php8.3-fpm.

Cek log Nginx:

sudo tail -n 50 /var/log/nginx/error.log

Cek log PHP-FPM:

sudo journalctl -u php8.3-fpm -n 50

Penyebab Umum

• PHP-FPM mati
• upstream aplikasi mati
• socket path salah
• backend timeout
• RAM habis
• permission socket bermasalah

Quick Fix

Restart backend terkait.

Contoh PHP-FPM:

sudo systemctl restart php8.3-fpm

Reload Nginx setelah memastikan config valid:

sudo nginx -t
sudo systemctl reload nginx

⚠️ PRO TIP: Selalu jalankan nginx -t sebelum reload atau restart Nginx. Config salah bisa membuat service gagal naik.

Pencegahan

• monitoring PHP-FPM/upstream
• tuning worker dan memory limit
• healthcheck backend
• alert untuk 5xx rate
• review timeout Nginx dan aplikasi

Takeaway

Nginx 502 biasanya bukan berarti Nginx rusak. Sering kali masalahnya ada di backend yang tidak siap menjawab request.

7. Service Gagal Start

Service gagal start itu seperti mesin yang menolak menyala.

Jangan langsung panik. Biasanya systemd dan log sudah memberi petunjuk yang cukup jelas.

Gejala

• service tidak bisa start
• status service failed
• aplikasi tidak bisa diakses
• restart service selalu gagal

Cara Cek

Cek status service:

sudo systemctl status service-name

Cek log service:

sudo journalctl -u service-name -n 50

Cek service yang failed:

systemctl --failed

Penyebab Umum

• config invalid
• port sudah dipakai
• permission salah
• file environment hilang
• dependency belum jalan
• path binary salah

Quick Fix

Baca error dari systemctl status dan journalctl.

Kalau service Nginx, validasi config:

sudo nginx -t

Kalau service custom, cek file unit:

sudo systemctl cat service-name

Setelah memperbaiki unit file:

sudo systemctl daemon-reload
sudo systemctl restart service-name

Pencegahan

• validasi config sebelum restart
• dokumentasikan perubahan service
• gunakan environment file yang jelas
• monitor service failed

Takeaway

Saat service gagal start, jangan menebak. systemctl status dan journalctl biasanya sudah menunjukkan arah masalah.

8. Port Sudah Dipakai

Masalah ini sering muncul setelah deploy service baru.

Service ingin listen di port tertentu, tapi port itu sudah dipakai process lain.

Akhirnya service gagal start.

Gejala

• service gagal bind port
• muncul error address already in use
• aplikasi tidak bisa start
• port yang diharapkan tidak aktif

Cara Cek

Lihat semua port listening:

sudo ss -tulpn

Cek port tertentu:

sudo ss -tulpn | grep :80

Atau gunakan lsof:

sudo lsof -i :80

Penyebab Umum

• service lama belum dimatikan
• dua aplikasi memakai port sama
• container publish port bentrok
• Nginx/Apache sama-sama listen port 80

Quick Fix

Matikan service yang tidak dibutuhkan:

sudo systemctl stop service-name

Atau ubah port aplikasi di config.

Kalau pakai Docker, cek port mapping:

docker ps

Pencegahan

• dokumentasikan port service
• gunakan reverse proxy dengan rapi
• hindari menjalankan dua web server di port sama
• review docker-compose sebelum deploy

Takeaway

Port conflict mudah dicari dengan ss atau lsof. Jangan restart random sebelum tahu process mana yang memegang port.

9. MySQL/MariaDB Crash

Database crash biasanya bikin efek domino.

Aplikasi error, login gagal, transaksi berhenti, dan semua orang mulai bertanya:

“Database-nya kenapa?”

Gejala

• aplikasi gagal connect database
• MySQL/MariaDB mati
• query timeout
• muncul error connection refused
• service database sering restart

Cara Cek

Cek status MySQL:

sudo systemctl status mysql

Untuk MariaDB:

sudo systemctl status mariadb

Cek log:

sudo journalctl -u mysql -n 100

Atau:

sudo journalctl -u mariadb -n 100

Cek disk dan memory:

df -h
free -h

Cek OOM:

dmesg -T | grep -i "killed process"

Penyebab Umum

• disk full
• RAM habis
• OOM Killer
• table corruption
• konfigurasi buffer terlalu besar
• query berat
• koneksi terlalu banyak

Quick Fix

Start ulang service:

sudo systemctl restart mysql

Cek apakah service sudah aktif:

sudo systemctl status mysql

Cek koneksi:

mysql -u root -p

⚠️ PRO TIP: Kalau database crash karena disk full atau OOM, restart hanya solusi sementara. Penyebab resource harus tetap dibereskan.

Pencegahan

• monitoring disk, RAM, dan connection count
• aktifkan slow query log jika perlu
• tuning buffer sesuai kapasitas server
• backup rutin
• test restore backup

Takeaway

Database crash jarang berdiri sendiri. Selalu cek disk, RAM, log database, dan kemungkinan OOM.

10. SSL Certificate Expired

SSL expired sering terlihat sepele sampai browser user mulai menampilkan warning merah.

Masalah ini biasanya bukan karena aplikasi rusak, tapi karena proses renewal tidak berjalan.

Gejala

• browser menampilkan warning certificate expired
• HTTPS gagal
• user tidak bisa mengakses website dengan aman
• API client menolak koneksi TLS

Cara Cek

Jika memakai Certbot:

sudo certbot certificates

Cek certificate dari domain:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Penyebab Umum

• auto renew Certbot gagal
• DNS challenge gagal
• webroot challenge tidak bisa diakses
• cron/systemd timer renewal tidak jalan
• port 80 tertutup saat renewal

Quick Fix

Renew certificate:

sudo certbot renew

Test renewal:

sudo certbot renew --dry-run

Reload Nginx setelah renewal:

sudo systemctl reload nginx

Pencegahan

• monitoring expiry certificate
• test auto renew berkala
• pastikan port challenge terbuka
• alert sebelum certificate expired

Takeaway

SSL expired bisa dicegah dengan monitoring sederhana. Jangan tunggu browser user yang memberi tahu.

Bagian 3 - Masalah Network dan Akses

Masalah network sering terasa abu-abu.

Kadang service sebenarnya hidup, tapi tidak bisa diakses karena DNS, firewall, packet loss, atau SSH bermasalah.

Bagian ini fokus ke akses dan konektivitas.

11. Tidak Bisa SSH

Tidak bisa SSH ke server production itu rasanya seperti berdiri di depan rumah sendiri tapi kuncinya patah.

Masalahnya bisa dari server, network, firewall, sampai key permission.

Gejala

• SSH timeout
• permission denied
• connection refused
• host key warning
• server bisa ping tapi tidak bisa SSH

Cara Cek

Cek konektivitas dasar:

ping server-ip

Cek port SSH:

nc -vz server-ip 22

Jika masih punya akses console/provider, cek service SSH:

sudo systemctl status ssh

Atau di beberapa distro:

sudo systemctl status sshd

Cek firewall:

sudo ufw status

Penyebab Umum

• firewall menutup port 22
• service SSH mati
• IP server salah
• user salah
• key permission salah
• Fail2Ban memblokir IP
• password login dimatikan sebelum key benar

Quick Fix

Jika terkunci karena UFW dan masih punya console:

sudo ufw allow OpenSSH
sudo systemctl restart ssh

Cek permission key di client:

chmod 600 ~/.ssh/id_ed25519

Cek permission di server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Pencegahan

• jangan tutup session lama sebelum test login baru
• allow SSH sebelum enable firewall
• gunakan SSH key dengan benar
• dokumentasikan akses emergency console

🚨 DANGER ZONE: Jangan matikan PasswordAuthentication sebelum memastikan SSH key benar-benar bisa login dari terminal baru.

Takeaway

Saat SSH bermasalah, bedakan dulu: timeout, refused, atau permission denied. Masing-masing mengarah ke penyebab berbeda.

12. DNS Error

DNS sering jadi tersangka yang diam-diam benar.

Aplikasi sehat, server hidup, tapi domain tidak resolve atau mengarah ke IP lama.

Gejala

• domain tidak bisa dibuka
• sebagian user bisa akses, sebagian tidak
• domain mengarah ke IP salah
• email/API gagal karena hostname tidak resolve

Cara Cek

Cek DNS record:

dig example.com

Cek record tertentu:

dig A example.com

Cek nameserver:

dig NS example.com

Cek lewat resolver tertentu:

dig @8.8.8.8 example.com

Penyebab Umum

• record DNS salah
• propagation belum selesai
• TTL terlalu lama
• nameserver belum berubah
• DNS provider bermasalah
• cache DNS client masih lama

Quick Fix

Validasi record di DNS provider.

Cek apakah domain sudah mengarah ke IP yang benar:

dig +short example.com

Flush DNS cache di sisi client jika perlu.

Pencegahan

• turunkan TTL sebelum migrasi
• dokumentasikan DNS record penting
• monitoring DNS
• hindari perubahan DNS mendadak tanpa rencana rollback

Takeaway

Kalau service hidup tapi domain bermasalah, cek DNS dari beberapa resolver. Jangan hanya percaya hasil dari laptop sendiri.

13. Packet Loss Tinggi

Packet loss adalah masalah yang bikin aplikasi terasa “kadang bisa, kadang tidak”.

Ini sering membuat troubleshooting melelahkan karena gejalanya tidak selalu konsisten.

Gejala

• koneksi putus-putus
• SSH sering freeze
• request timeout sesekali
• latency naik turun
• user dari lokasi tertentu lebih sering error

Cara Cek

Ping target:

ping 8.8.8.8

Gunakan MTR untuk melihat jalur network:

mtr google.com

Atau mode report:

mtr -rw google.com

Penyebab Umum

• network provider bermasalah
• routing issue
• VPS host/node overload
• firewall/rate limit
• masalah di sisi ISP user

Quick Fix

Kumpulkan bukti packet loss:

mtr -rw target-domain.com

Bandingkan dari beberapa lokasi jika memungkinkan.

Jika loss terjadi di upstream provider, eskalasi ke provider dengan hasil MTR.

Pencegahan

• monitoring latency dan packet loss
• gunakan provider yang stabil
• multi-region untuk aplikasi penting
• punya status page atau jalur komunikasi incident

Takeaway

Packet loss perlu bukti. MTR lebih membantu daripada sekadar bilang “internetnya lambat”.

14. Firewall Salah Config

Service bisa saja hidup, port listening, tapi tetap tidak bisa diakses dari luar.

Sering kali penyebabnya firewall.

Gejala

• service aktif tapi tidak bisa diakses
• port terlihat listening di server
• akses dari localhost bisa, dari luar tidak bisa
• SSH atau HTTP tiba-tiba timeout

Cara Cek

Cek UFW:

sudo ufw status verbose

Cek iptables:

sudo iptables -L -n -v

Cek port listening:

sudo ss -tulpn

Dari luar server, test port:

nc -vz server-ip 443

Penyebab Umum

• port belum di-allow
• rule deny terlalu agresif
• urutan rule salah
• security group cloud belum dibuka
• firewall provider berbeda dari firewall OS

Quick Fix

Allow port HTTPS:

sudo ufw allow 443

Allow HTTP:

sudo ufw allow 80

Allow SSH:

sudo ufw allow OpenSSH

Pencegahan

• dokumentasikan firewall rule
• cek firewall OS dan security group cloud
• jangan enable firewall sebelum allow SSH
• review rule setelah perubahan service

⚠️ PRO TIP: Di cloud/VPS, firewall bisa ada dua lapis: firewall OS dan firewall/security group dari provider.

Takeaway

Kalau service hidup tapi tidak bisa diakses, cek tiga hal: port listening, firewall OS, dan firewall provider.

Bagian 4 - Masalah File, Permission, Container, dan Sistem

Tidak semua incident berasal dari resource atau network.

Kadang masalahnya ada di permission, filesystem, Docker, cron, atau reboot mendadak.

Bagian ini membahas problem yang sering terlihat kecil, tapi efeknya bisa besar di production.

15. Permission Denied

Error ini pendek, tapi sering bikin lama.

Permission denied

Bisa muncul saat aplikasi upload file, Nginx membaca folder, script backup menulis output, atau user menjalankan command tertentu.

Gejala

• aplikasi gagal upload file
• script tidak bisa dijalankan
• web server tidak bisa membaca file
• backup gagal menulis file
• muncul error permission denied

Cara Cek

Cek user aktif:

whoami
id

Cek ownership dan permission:

ls -lah

Cek folder target:

ls -ld /path/to/folder

Cek permission setiap level path:

namei -l /var/www/app/storage/file.txt

Penyebab Umum

• owner file salah
• group salah
• permission terlalu ketat
• folder parent tidak punya execute permission
• process aplikasi berjalan sebagai user berbeda

Quick Fix

Contoh untuk folder aplikasi web yang perlu ditulis oleh www-data:

sudo chown -R www-data:www-data /var/www/app/storage
sudo chmod -R 775 /var/www/app/storage

🚨 DANGER ZONE: Jangan biasakan chmod -R 777 /var/www/app di production. Itu memang sering membuat error hilang, tapi juga membuka risiko keamanan yang besar.

Pencegahan

• pahami user yang menjalankan process aplikasi
• gunakan owner/group yang tepat
• batasi permission sesuai kebutuhan
• hindari chmod 777
• dokumentasikan permission folder penting

Takeaway

Permission denied bukan alasan untuk langsung chmod 777. Cari dulu user process, owner file, group, dan permission parent folder.

16. Filesystem Read-Only

Ini salah satu masalah yang lebih serius.

Server masih hidup, tapi tidak bisa menulis file.

Kadang Linux me-remount filesystem menjadi read-only untuk melindungi data ketika mendeteksi error disk atau filesystem.

Gejala

• tidak bisa membuat file
• service gagal menulis log
• database error saat write
• muncul pesan read-only file system

Cara Cek

Cek mount option root filesystem:

mount | grep " / "

Cek kernel log:

dmesg -T | tail -n 100

Cek filesystem usage:

df -h

Penyebab Umum

• disk error
• filesystem corruption
• storage bermasalah
• kernel me-remount filesystem ke read-only
• masalah underlying storage di VPS/provider

Quick Fix

Jika filesystem benar-benar read-only karena error, biasanya butuh maintenance window.

Kemungkinan perlu reboot dan fsck:

sudo fsck /dev/sdXN

Ganti /dev/sdXN dengan device yang benar.

🚨 DANGER ZONE: Jangan asal menjalankan fsck pada filesystem yang sedang mounted dan aktif. Salah langkah bisa memperburuk kerusakan data.

Pencegahan

• monitoring disk health
• backup rutin
• gunakan storage reliable
• cek kernel log setelah incident
• jangan abaikan error I/O

Takeaway

Filesystem read-only bukan sekadar permission problem. Ini bisa menjadi tanda masalah storage yang serius.

17. Docker Container Restart Loop

Container restart loop sering terjadi setelah deploy.

Di dashboard kelihatan container “up”, lalu restart, lalu up lagi, lalu restart lagi.

Aplikasi tidak pernah benar-benar siap.

Gejala

• container terus restart
• aplikasi tidak bisa diakses
• status container Restarting
• log aplikasi berulang dari awal

Cara Cek

Cek container:

docker ps

Tampilkan semua container, termasuk yang mati:

docker ps -a

Baca log:

docker logs container-name

Follow log:

docker logs -f container-name

Inspect container:

docker inspect container-name

Penyebab Umum

• environment variable salah
• database belum ready
• dependency tidak bisa diakses
• command entrypoint error
• port conflict
• permission volume salah
• aplikasi crash saat startup

Quick Fix

Baca log container terlebih dahulu:

docker logs --tail=100 container-name

Cek environment dan volume di docker-compose.yml.

Restart setelah config diperbaiki:

docker compose up -d

Pencegahan

• gunakan healthcheck
• validasi env sebelum deploy
• pastikan dependency siap
• jangan menyimpan secret sembarangan
• logging container harus mudah dibaca

Takeaway

Docker restart loop hampir selalu meninggalkan petunjuk di docker logs. Baca log sebelum rebuild atau redeploy random.

18. Cron Tidak Jalan

Cron sering dianggap sederhana sampai job penting tidak jalan.

Backup gagal.
Script cleanup tidak jalan.
Report harian tidak terkirim.

Lalu semua orang baru sadar cron tidak sepolos itu.

Gejala

• script otomatis tidak berjalan
• backup tidak dibuat
• report tidak terkirim
• command manual berhasil, tapi via cron gagal

Cara Cek

Cek service cron:

sudo systemctl status cron

Cek crontab user aktif:

crontab -l

Cek crontab root:

sudo crontab -l

Cek log cron di Ubuntu/Debian:

grep CRON /var/log/syslog

Penyebab Umum

• service cron mati
• path command tidak lengkap
• script tidak executable
• environment cron berbeda dari shell interaktif
• permission file salah
• output error tidak dicatat

Quick Fix

Gunakan full path di cron.

Contoh buruk:

* * * * * backup.sh

Contoh lebih aman:

* * * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Pastikan script executable:

chmod +x /usr/local/bin/backup.sh

Pencegahan

• gunakan full path
• redirect output ke log
• monitor hasil cron
• dokumentasikan job penting
• test script dengan user yang sama seperti cron

Takeaway

Kalau command jalan manual tapi gagal via cron, curigai environment, path, permission, dan logging.

19. Server Tiba-Tiba Reboot

Server reboot sendiri adalah salah satu incident yang harus diinvestigasi serius.

Jangan hanya bilang “sudah normal lagi” lalu selesai.

Cari tahu penyebabnya.

Gejala

• uptime tiba-tiba kecil
• service restart semua
• user melaporkan downtime singkat
• log menunjukkan boot baru

Cara Cek

Cek riwayat reboot:

last reboot

Cek log boot sebelumnya:

journalctl -b -1

Cek error kernel dari boot sebelumnya:

journalctl -b -1 -p err

Cek OOM:

dmesg -T | grep -i "killed process"

Penyebab Umum

• OOM parah
• kernel panic
• provider melakukan reboot host
• maintenance dari cloud provider
• hardware issue
• admin lain reboot manual
• power issue untuk server fisik

Quick Fix

Pastikan semua service penting sudah kembali aktif:

systemctl --failed

Cek uptime:

uptime

Cek aplikasi utama.

Jika ada service failed:

sudo systemctl restart service-name

Pencegahan

• monitoring uptime
• alert saat reboot
• audit log admin
• cek pengumuman provider
• review kernel log
• backup dan HA untuk service kritikal

Takeaway

Server yang “sudah hidup lagi” belum tentu masalahnya selesai. Reboot mendadak harus tetap dicari penyebabnya.

20. Semua Normal Tapi Website Tetap Lemot

Ini kasus yang paling sering bikin diskusi panjang.

CPU normal.
RAM aman.
Disk tidak penuh.
Nginx hidup.
Database hidup.

Tapi website tetap lambat.

Di titik ini, masalah mungkin bukan di server dasar, tapi di aplikasi, database query, external API, atau dependency lain.

Gejala

• resource server terlihat normal
• request tetap lambat
• hanya endpoint tertentu yang lambat
• halaman tertentu timeout
• aplikasi terasa berat meskipun server sehat

Cara Cek

Cek response time dengan curl:

curl -o /dev/null -s -w "DNS: %{time_namelookup}
Connect: %{time_connect}
TLS: %{time_appconnect}
TTFB: %{time_starttransfer}
Total: %{time_total}
" https://example.com

Cek log Nginx access untuk status code dan pola request:

sudo tail -n 100 /var/log/nginx/access.log

Cek error log:

sudo tail -n 100 /var/log/nginx/error.log

Jika memakai database, cek slow query log.

Jika aplikasi memanggil API eksternal, cek latency dependency tersebut.

Penyebab Umum

• query database lambat
• external API timeout
• DNS lambat
• lock database
• endpoint tertentu tidak optimal
• cache tidak aktif
• antrian job menumpuk

Quick Fix

Cari apakah lambatnya terjadi di semua endpoint atau hanya endpoint tertentu.

Cek dari server langsung:

curl -I http://localhost

Bandingkan dengan akses dari luar:

curl -I https://example.com

Kalau dari localhost cepat tapi dari luar lambat, curigai network, DNS, TLS, CDN, atau routing.

Kalau dari localhost juga lambat, curigai aplikasi atau database.

Pencegahan

• gunakan APM jika memungkinkan
• aktifkan slow query log
• monitor latency per endpoint
• caching untuk request berat
• observability untuk dependency eksternal

💡 Insight: Server normal bukan berarti aplikasi sehat. Resource aman hanya menutup satu kemungkinan, bukan menyelesaikan investigasi.

Takeaway

Kalau semua resource normal tapi website tetap lambat, pindahkan fokus dari server dasar ke aplikasi, database, dan dependency eksternal.

Alur Troubleshooting yang Sehat Saat Incident

Saat incident terjadi, jangan langsung lompat ke solusi.

Gunakan alur sederhana ini:

1. Pahami gejala
2. Tentukan scope masalah
3. Cek resource dasar
4. Cek service terkait
5. Baca log
6. Cocokkan timestamp
7. Buat hipotesis
8. Uji satu per satu
9. Lakukan fix paling aman
10. Dokumentasikan hasil

Contoh urutan cepat saat website down:

uptime
free -h
df -h
sudo systemctl status nginx
sudo tail -n 50 /var/log/nginx/error.log
sudo ss -tulpn

Lalu lanjut sesuai hasil.

Jangan langsung:

• reboot server
• restart semua service
• hapus file random
• chmod 777
• kill -9 tanpa tahu process-nya
• copy-paste command dari internet tanpa paham efeknya

⚠️ PRO TIP: Restart boleh. Tapi sebelum restart, ambil bukti dulu: status service, log, resource, dan waktu kejadian. Kalau tidak, jejak penyebab bisa hilang.

Checklist Cepat Saat Server Bermasalah

Gunakan checklist ini saat kamu mulai panik.

### 1. Cek server hidup dan load
uptime

### 2. Cek memory
free -h

### 3. Cek disk
df -h

### 4. Cek inode
df -i

### 5. Cek process berat
ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head

### 6. Cek service failed
systemctl --failed

### 7. Cek port listening
sudo ss -tulpn

### 8. Cek log kernel terakhir
dmesg -T | tail -n 50

Kalau masalah terkait service tertentu:

sudo systemctl status service-name
sudo journalctl -u service-name -n 100

Referensi Resmi dan Bacaan Lanjutan

Supaya troubleshooting kamu makin akurat, rujuk dokumentasi resmi berikut:

• Docker CLI reference
• Nginx Beginner's Guide
• systemd journalctl manual

Kalau kamu ingin memperkuat fondasi operasional Linux, lanjutkan juga ke konten internal berikut:

• Lihat semua series
• Lihat semua download resource
• Lihat semua artikel blog

Penutup

Troubleshooting Linux production bukan soal hafal semua command.

Command bisa dicari. Dokumentasi bisa dibuka. Tutorial bisa dibaca.

Yang lebih penting adalah cara berpikir.

Saat incident terjadi, kamu perlu tetap tenang, membaca gejala, mempersempit kemungkinan, lalu memperbaiki dengan risiko paling kecil.

Semakin sering kamu menghadapi masalah production, semakin kamu sadar bahwa banyak incident sebenarnya punya pola yang berulang.

Disk penuh.
RAM habis.
Service mati.
Firewall salah.
Permission kacau.
Container restart loop.
Database crash.

Awalnya semua terlihat menakutkan.

Tapi setelah kamu tahu pola dan command dasarnya, troubleshooting jadi lebih masuk akal.

Bukan berarti tidak akan panik sama sekali.

Semua engineer juga pernah panik lihat layar penuh error.

Bedanya, engineer yang terlatih tahu harus mulai dari mana.

Jadi, jangan takut troubleshooting.

Mulai dari gejala.
Baca log.
Cek resource.
Validasi hipotesis.
Catat hasilnya.

Pelan-pelan, incident yang dulu terasa seperti bencana akan berubah menjadi masalah teknis yang bisa diurai satu per satu.

Pertanyaan untuk Pembaca

Dari 20 masalah di atas, mana yang paling sering kamu temui di server production?

Atau ada command andalan yang belum masuk list ini?

Share di kolom komentar. Bisa jadi pengalamanmu membantu sysadmin lain yang sedang menghadapi incident serupa.