ABDURROZAK.MY.ID // DEBIAN LINUX SERVER

TROUBLESHOOTINGLENGKAP

Panduan troubleshooting server Debian secara detail, sistematis, dan mendalam. Dari gejala → diagnosis → solusi, lengkap dengan command dan contoh output terminal.

TOPIK15

SOLUSI80+

COMMAND200+

BACA120 MENIT

ABDUR ROZAK, S.Kom.Web Developer & Network Educator - abdurrozak.my.id

TROUBLESHOOTING

METODOLOGI TROUBLESHOOTING

Sebelum masuk ke kasus spesifik, pahami alur berpikir yang benar. Troubleshooting yang baik selalu sistematis, bukan trial-and-error membabi buta.

Prinsip Dasar

Reproduksi masalah — Pastikan Anda bisa memicu gejala secara konsisten.
Kumpulkan fakta — Log, status service, resource, error message. Jangan tebak.
Isolasi — Ubah satu variabel saja setiap kali, catat hasilnya.
Dari luar ke dalam — Mulai dari network → service → aplikasi → data.
Dokumentasikan — Catat apa yang sudah dicoba agar tidak mengulang langkah yang sama.

Urutan Diagnosis Standar

DIAGNOSIS ORDER

# 1. Apakah server hidup dan bisa di-ping?
ping -c 4 SERVER_IP

# 2. Apakah port service terbuka?
nmap -p 22,80,443 SERVER_IP
ss -tulpn

# 3. Apakah service berjalan?
systemctl status SERVICE

# 4. Apakah ada error di log?
journalctl -u SERVICE -xe --no-pager | tail -50
journalctl -p err -b --no-pager | tail -30

# 5. Apakah resource cukup?
df -h
free -h
uptime

Peringatan: Jangan langsung restart server atau service sebelum mengumpulkan log. Restart sering menghapus jejak error yang berharga.

TROUBLESHOOTING

SERVER TIDAK BISA DIAKSES (SSH / NETWORK)

Ini kasus paling sering. Gejala: tidak bisa SSH, website down, atau ping timeout. Ikuti langkah berurutan di bawah.

Server tidak merespons ping sama sekali

Kemungkinan penyebab: Server mati, network interface down, firewall memblokir ICMP, atau masalah di sisi jaringan (routing/ISP).

LANGKAH DIAGNOSIS

# Dari mesin lokal Anda:
ping -c 4 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Host Unreachable
--- 192.168.1.100 ping statistics ---
4 packets transmitted, 0 received, +4 errors

traceroute 192.168.1.100
# Lihat di hop mana paket berhenti

# Jika Anda punya akses console (VPS panel / IPMI / KVM):
ip link show
ip addr show
ip route show
systemctl status networking NetworkManager

Solusi yang sering berhasil:

Di VPS: cek status instance di panel provider (kadang server ter-suspend atau mati).
Interface down → sudo ip link set eth0 up lalu sudo dhclient eth0 atau restart networking.
Salah konfigurasi IP static → perbaiki di /etc/network/interfaces atau netplan, lalu sudo systemctl restart networking.
Kabel/virtual NIC terputus (di environment virtualisasi).

Ping berhasil, tapi SSH timeout / connection refused

Ping OK berarti layer 3 (IP) hidup. Masalah ada di port 22, service SSH, atau firewall.

CEK PORT & SERVICE

nmap -p 22 SERVER_IP
PORT   STATE    SERVICE
22/tcp filtered ssh     ← firewall memblokir
# atau
22/tcp closed   ssh     ← tidak ada yang listening
# atau
22/tcp open     ssh     ← port terbuka, masalah di auth/config

# Di server (jika punya console):
ss -tlnp | grep :22
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=789,fd=3))

sudo systemctl status ssh
sudo journalctl -u ssh -xe --no-pager | tail -30

Penyelesaian umum:

Port filtered → Firewall (UFW/iptables/security group cloud) memblokir. Buka port: sudo ufw allow 22/tcp atau port custom Anda.
Port closed → Service SSH tidak berjalan: sudo systemctl start ssh && sudo systemctl enable ssh.
Port open tapi masih gagal → Cek /etc/ssh/sshd_config (AllowUsers, PermitRootLogin, Port). Restart ssh setelah ubah config.
Salah port: jika SSH di port 2222, gunakan ssh -p 2222 user@host.

SSH minta password terus / Permission denied (publickey)

DEBUG SSH CLIENT

ssh -vvv user@SERVER_IP
# Output verbose menunjukkan tahap mana yang gagal

Penyebab & solusi:

Public key belum ada di ~/.ssh/authorized_keys di server.
Permission salah: ~/.ssh harus 700, authorized_keys harus 600, owned by user.
PasswordAuthentication no di sshd_config sementara key belum terpasang → Anda terkunci. Pakai console untuk perbaiki.
SELinux/AppArmor jarang jadi biang di Debian, tapi permission file sangat krusial.

PERBAIKI PERMISSION SSH

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh
sudo systemctl restart ssh

TROUBLESHOOTING

DISK PENUH / NO SPACE LEFT

Gejala klasik: aplikasi error "No space left on device", log berhenti tertulis, APT gagal, database crash. Segera diagnosa sebelum sistem makin rusak.

Cara cepat menemukan penyebab disk penuh

DIAGNOSA DISK

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        20G   19G  200M  99% /
/dev/sda2       100G   40G   55G  43% /var

df -i
# Cek apakah inode yang habis (bukan space)
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda1      1310720 1310000   720   100% /

sudo du -xh / --max-depth=2 2>/dev/null | sort -hr | head -20
# Tampilkan direktori paling boros

sudo find / -xdev -type f -size +100M 2>/dev/null | head -20
# Cari file lebih besar dari 100MB

Penjelasan:

df -h — Melihat penggunaan space per filesystem.
df -i — Melihat penggunaan inode. Bisa penuh meski space masih ada (banyak file kecil).
du -xh — Menghitung ukuran aktual isi direktori (abaikan mount lain).

Solusi membersihkan disk dengan aman

PEMBERSIHAN AMAN

# 1. Hapus cache APT
sudo apt clean
sudo apt autoclean
sudo apt autoremove --purge

# 2. Bersihkan journal log (simpan 3 hari terakhir)
sudo journalctl --vacuum-time=3d
sudo journalctl --vacuum-size=200M

# 3. Hapus log lama yang sudah di-rotate
sudo find /var/log -type f -name '*.gz' -delete
sudo find /var/log -type f -name '*.1' -delete

# 4. Bersihkan temporary
sudo rm -rf /tmp/*
sudo rm -rf /var/tmp/*

# 5. Cek Docker jika terinstall (sering makan banyak space)
sudo docker system prune -af
sudo docker volume prune -f

# 6. Setelah membersihkan, cek lagi
df -h

Jangan sembarangan hapus isi /var/lib (database, docker data, dll) atau /home tanpa memastikan isinya.

Disk penuh karena log yang meledak

Log bisa tumbuh sangat cepat jika aplikasi error berulang atau debug level terlalu verbose.

LOG MELEDAK

sudo du -sh /var/log/* | sort -hr | head -10
sudo tail -100 /var/log/syslog
sudo journalctl --disk-usage

# Batasi ukuran journal secara permanen
sudo nano /etc/systemd/journald.conf
# Set: SystemMaxUse=200M
sudo systemctl restart systemd-journald

TROUBLESHOOTING

MEMORY / CPU TINGGI ATAU SERVER LELET

Server terasa lambat, load average tinggi, atau OOM (Out of Memory) killer aktif.

Cara diagnosa memory pressure

CEK MEMORY

free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       3.5Gi       100Mi        50Mi       200Mi       150Mi
Swap:          2.0Gi       1.8Gi       200Mi

ps aux --sort=-%mem | head -15
# Proses paling boros RAM

sudo dmesg | grep -i 'out of memory'
sudo journalctl -k | grep -i oom
# Cek apakah OOM killer pernah aktif

Interpretasi:

available sangat kecil + swap hampir penuh → memory pressure nyata.
Proses tertentu makan ratusan MB/GB → pertimbangkan restart service itu atau naikkan RAM.
OOM killer muncul di dmesg → kernel terpaksa membunuh proses. Cari proses yang di-kill dan perbaiki root cause (memory leak / under-provision).

Cara diagnosa CPU tinggi

CEK CPU

uptime
14:30:01 up 10 days,  3:22,  2 users,  load average: 4.50, 3.80, 2.10
# Load 4.5 di mesin 2-core = sudah overloaded

top -bn1 | head -20
ps aux --sort=-%cpu | head -15
mpstat 1 5
# Perlu paket sysstat: sudo apt install sysstat

Solusi umum:

Proses runaway → kill PID atau kill -9 PID (terakhir).
Service bocor / infinite loop → restart service, cek log, update software.
Load tinggi tapi CPU idle → kemungkinan I/O wait (disk lambat). Cek dengan iostat -xz 1.

Menambah swap darurat

TAMBAH SWAP

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h

Swap membantu menghindari OOM, tetapi jauh lebih lambat dari RAM. Anggap ini solusi sementara, bukan pengganti upgrade RAM.

TROUBLESHOOTING

SERVICE GAGAL START / FAILED

Service menampilkan status failed atau inactive (dead) padahal seharusnya berjalan.

Alur diagnosa service failed

DIAGNOSA SERVICE

systemctl --failed
  UNIT           LOAD   ACTIVE SUB    DESCRIPTION
● nginx.service  loaded failed failed A high performance web server

sudo systemctl status nginx
sudo journalctl -u nginx -xe --no-pager | tail -50
sudo systemctl cat nginx
# Lihat unit file yang dipakai

Penjelasan langkah:

systemctl --failed — Ringkasan semua unit yang gagal.
status — Menampilkan exit code + cuplikan log terakhir.
journalctl -u ... -xe — Log detail + penjelasan systemd.

Penyebab umum service gagal & solusinya

Port already in use — Service lain memakai port yang sama. Cek: ss -tlnp | grep :80. Stop service yang bentrok atau ganti port.
Config syntax error — Nginx: nginx -t. Apache: apache2ctl configtest. Perbaiki config lalu restart.
Permission / path salah — Binary tidak ditemukan, atau user service tidak punya izin ke file/directory.
Dependency belum siap — Database belum start saat aplikasi start. Atur After= dan Requires= di unit file.
Environment / env file hilang — Cek EnvironmentFile= di unit file.

PERBAIKI & RESET

sudo systemctl reset-failed
sudo systemctl daemon-reload
sudo systemctl restart nginx
sudo systemctl status nginx

TROUBLESHOOTING

MASALAH NETWORK & DNS

DNS resolution gagal (bisa ping IP, tidak bisa ping domain)

CEK DNS

cat /etc/resolv.conf
nameserver 8.8.8.8\nnameserver 1.1.1.1

ping -c 2 8.8.8.8
# Jika ini berhasil, network OK

ping -c 2 google.com
# Jika ini gagal → masalah DNS

dig google.com
nslookup google.com
resolvectl status

Solusi:

Isi /etc/resolv.conf dengan DNS publik (8.8.8.8 / 1.1.1.1).
Jika memakai systemd-resolved, edit /etc/systemd/resolved.conf lalu systemctl restart systemd-resolved.
Di cloud, kadang DNS internal provider wajib dipakai — cek dokumentasi VPS Anda.

Routing / tidak ada default gateway

CEK ROUTING

ip route show
default via 192.168.1.1 dev eth0\n192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100

# Jika tidak ada baris 'default via ...':
sudo ip route add default via 192.168.1.1 dev eth0
# Lalu buat permanen di /etc/network/interfaces atau NetworkManager

TROUBLESHOOTING

WEB SERVER ERROR (NGINX / APACHE)

502 Bad Gateway / 504 Gateway Timeout

Nginx/Apache berjalan, tapi backend (PHP-FPM, Node, upstream) tidak merespons.

DIAGNOSA 502/504

sudo systemctl status php8.2-fpm
sudo systemctl status nginx
sudo tail -50 /var/log/nginx/error.log
connect() failed (111: Connection refused) while connecting to upstream
upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock"

ss -tlnp | grep -E 'php|9000|3000'
# Pastikan backend listening

Solusi umum:

PHP-FPM mati → sudo systemctl restart php8.2-fpm.
Socket path di Nginx tidak cocok dengan PHP-FPM → samakan path di www.conf dan fastcgi_pass.
Upstream timeout → naikkan proxy_read_timeout / fastcgi_read_timeout.

403 Forbidden / 404 Not Found

403 — Permission directory/file, atau deny all di config. Cek: ls -la /var/www/..., pastikan www-data bisa read. Directory butuh execute bit (chmod 755).
404 — Path salah, root directive salah, atau file memang tidak ada. Cek root / DocumentRoot dan nama file.

CEK PERMISSION WEB

ls -la /var/www/html
sudo namei -l /var/www/html/index.html
ps aux | grep -E 'nginx|apache' | head -5
# Lihat user yang menjalankan worker

Config test gagal

TEST CONFIG

sudo nginx -t
nginx: [emerg] unexpected "}" in /etc/nginx/sites-enabled/example.com:42
nginx: configuration file /etc/nginx/nginx.conf test failed

sudo apache2ctl configtest

Perbaiki baris yang ditunjuk error, lalu test lagi sampai "syntax is ok" / "Syntax OK". Baru kemudian reload.

TROUBLESHOOTING

DATABASE BERMASALAH (MariaDB / PostgreSQL)

MariaDB/MySQL tidak bisa start

DIAGNOSA MYSQL

sudo systemctl status mariadb
sudo journalctl -u mariadb -xe --no-pager | tail -40
sudo tail -50 /var/log/mysql/error.log

Penyebab sering:

Disk penuh (InnoDB tidak bisa write).
Corrupt table / ibdata.
Konfigurasi memory terlalu besar (innodb_buffer_pool_size > RAM tersedia).
Permission /var/lib/mysql salah.

PERBAIKI DASAR

df -h
sudo chown -R mysql:mysql /var/lib/mysql
sudo systemctl restart mariadb

Access denied for user

CEK USER MYSQL

sudo mysql -u root -p
# Lalu di dalam MariaDB:
SELECT user,host FROM mysql.user;
SHOW GRANTS FOR 'myuser'@'localhost';

Pastikan user ada, host-nya benar (localhost vs %), dan password sesuai. Aplikasi yang konek via TCP (127.0.0.1) berbeda dengan socket (localhost).

PostgreSQL connection refused / peer auth failed

CEK POSTGRES

sudo systemctl status postgresql
sudo -u postgres psql -c 'SELECT version();'
sudo tail -30 /var/log/postgresql/postgresql-*-main.log

Edit pg_hba.conf untuk metode autentikasi (peer/md5/scram). Setelah ubah: sudo systemctl reload postgresql.

TROUBLESHOOTING

PERMISSION DENIED & AKSES FILE

Permission denied saat akses file/directory

DIAGNOSA PERMISSION

ls -la /path/ke/file
-rw------- 1 root root 1234 Mar 11 10:00 secret.conf

namei -l /path/ke/file
# Menampilkan permission setiap komponen path

id
groups

Solusi:

File milik root, Anda user biasa → sudo atau ubah ownership: sudo chown user:user file.
Directory tanpa bit execute → chmod 755 dir (perlu x untuk bisa masuk).
ACL memblokir → cek getfacl file.

Script tidak bisa dijalankan (Permission denied)

FIX EXECUTE

ls -l script.sh
chmod +x script.sh
./script.sh
# Atau panggil via interpreter:
bash script.sh

Pastikan baris pertama ada shebang yang benar: #!/bin/bash atau #!/usr/bin/env python3.

TROUBLESHOOTING

MASALAH BOOT & KERNEL

Server tidak boot / stuck di GRUB

Gunakan console provider (VNC/IPMI/KVM) atau boot dari live USB.

Di menu GRUB pilih Advanced options → kernel lama yang masih bagus.
Atau pilih recovery mode.
Dari live USB: mount root filesystem, chroot, lalu perbaiki.

RECOVERY DARI LIVE USB

sudo mount /dev/sda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt

update-grub
grub-install /dev/sda
exit
sudo reboot

Kernel panic / failed to mount root

UUID di /etc/fstab salah setelah ganti disk → boot recovery, perbaiki fstab (pakai blkid untuk lihat UUID baru).
Initramfs rusak → dari chroot: update-initramfs -u -k all.
Filesystem corrupt → fsck -f /dev/sdXN (dari live, unmounted).

TROUBLESHOOTING

APT / PACKAGE ERROR

E: Could not get lock / dpkg locked

FIX LOCK

sudo lsof /var/lib/dpkg/lock-frontend
ps aux | grep -E 'apt|dpkg'
# Jika tidak ada proses apt yang jalan:
sudo rm /var/lib/dpkg/lock-frontend
sudo rm /var/lib/apt/lists/lock
sudo rm /var/cache/apt/archives/lock
sudo dpkg --configure -a
sudo apt update

Dependency broken / Unmet dependencies

FIX DEPENDENCY

sudo apt --fix-broken install
sudo dpkg --configure -a
sudo apt install -f
sudo apt update && sudo apt full-upgrade

404 Not Found saat apt update

Repository URL sudah tidak valid (release diganti, mirror down, atau sources.list mengarah ke rilis lama yang diarsipkan).

PERBAIKI REPO

cat /etc/apt/sources.list
sudo nano /etc/apt/sources.list
# Pastikan codename sesuai (bookworm, bukan stretch/buster yang sudah EOL tanpa archive)
sudo apt update

TROUBLESHOOTING

FIREWALL MENGUNCI AKSES

Terkunci karena UFW (SSH port tertutup)

Jika Anda masih punya akses console (panel VPS / IPMI):

BUKA KEMBALI SSH

sudo ufw allow 22/tcp
sudo ufw allow 2222/tcp
# Jika pakai port custom
sudo ufw status numbered
sudo ufw reload
# Atau nonaktifkan sementara:
sudo ufw disable

Jika sama sekali tidak ada console, hubungi support provider untuk recovery console atau reset firewall dari panel.

Rules UFW tidak berjalan sesuai harapan

DEBUG UFW

sudo ufw status verbose
sudo iptables -L -n -v
sudo iptables -L INPUT -n -v --line-numbers
# Urutan rules penting — rule pertama yang match akan dipakai

TROUBLESHOOTING

ANALISIS LOG SECARA MENDALAM

Log adalah sumber kebenaran. Belajar membacanya mempercepat troubleshooting berkali lipat.

Command penting untuk membaca log

LOG COMMANDS

journalctl -xe
# Log terbaru + penjelasan systemd

journalctl -p err -b
# Hanya error sejak boot terakhir

journalctl -u nginx --since '1 hour ago'
# Log service tertentu dalam rentang waktu

journalctl -f
# Follow log real-time (seperti tail -f)

sudo tail -f /var/log/syslog
sudo tail -f /var/log/auth.log
sudo tail -f /var/log/nginx/error.log

sudo grep -i error /var/log/syslog | tail -20
sudo grep "Failed password" /var/log/auth.log | tail -20

Tips:

Selalu batasi waktu (--since) agar tidak kebanjiran output.
Cari pola berulang — error yang sama setiap detik biasanya root cause.
Correlasikan timestamp antar log (nginx error ↔ php-fpm ↔ mysql).

Log yang wajib dicek per jenis masalah

SSH / login → /var/log/auth.log, journalctl -u ssh
Web → /var/log/nginx/error.log atau /var/log/apache2/error.log
Database → /var/log/mysql/error.log, /var/log/postgresql/*.log
Sistem umum → journalctl -b -p err, /var/log/syslog
Kernel / hardware → dmesg, journalctl -k
Mail → /var/log/mail.log

TROUBLESHOOTING

SERVER LAMBAT / PERFORMA BURUK

Checklist performa cepat

PERF CHECK

uptime
# Load average vs jumlah core

free -h
# Memory & swap

df -h
# Disk space

iostat -xz 1 3
# Disk I/O (install sysstat)

ss -s
# Ringkasan koneksi network

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

Optimasi dasar yang sering menolong

Pastikan ada cukup RAM; tambah swap hanya sebagai buffer.
Log rotation aktif (logrotate) agar disk tidak penuh diam-diam.
Untuk web: enable gzip/brotli, cache static, HTTP/2, dan PHP OPcache.
Untuk database: sesuaikan innodb_buffer_pool_size (~50–70% RAM untuk dedicated DB server).
Matikan service yang tidak dipakai.
Monitor jangka panjang dengan Netdata / Prometheus + Grafana / Zabbix.

TROUBLESHOOTING

CHECKLIST TROUBLESHOOTING CEPAT

Simpan daftar ini. Saat insiden terjadi, kerjakan berurutan.

QUICK CHECKLIST

# === 1. HIDUPKAH SERVER? ===
ping -c 3 SERVER_IP

# === 2. PORT TERBUKA? ===
nmap -p 22,80,443 SERVER_IP

# === 3. SERVICE JALAN? ===
systemctl --failed
systemctl status ssh nginx mariadb

# === 4. RESOURCE CUKUP? ===
df -h
free -h
uptime

# === 5. ADA ERROR DI LOG? ===
journalctl -p err -b --no-pager | tail -30
journalctl -u SERVICE -xe --no-pager | tail -30

# === 6. NETWORK & DNS? ===
ip a
ip r
cat /etc/resolv.conf
ping -c 2 8.8.8.8
ping -c 2 google.com

# === 7. FIREWALL? ===
sudo ufw status verbose
sudo iptables -L -n | head -20

Setelah masalah selesai: catat root cause, langkah perbaikan, dan pencegahan agar tidak berulang. Dokumentasi singkat ini sangat berharga untuk insiden berikutnya.

Prinsip penutup: Jangan panik. Kumpulkan data dulu, ubah satu hal dalam satu waktu, verifikasi hasilnya, lalu lanjut. Hampir semua masalah server bisa dilacak dengan systemctl, journalctl, df, free, dan log aplikasi.

ABDURROZAK.MY.ID // TERHUBUNG

JARINGAN SOSIAL

Temukan saya di berbagai platform digital

s.id GitHub Instagram Threads Facebook TikTok YT Teacher WhatsApp Email