Linux Server dikenal stabil, fleksibel, dan banyak digunakan untuk menjalankan berbagai layanan seperti website, database, DNS, file server, aplikasi, container, virtual machine, hingga sistem monitoring.

Namun, stabil bukan berarti bebas masalah.

Dalam praktik administrasi server, hampir setiap sysadmin pernah menghadapi kondisi seperti disk tiba-tiba penuh, RAM habis, CPU mencapai 100%, SSH tidak bisa digunakan, website tidak dapat diakses, atau service gagal berjalan setelah perubahan konfigurasi.

Masalah tersebut terkadang terlihat sederhana, tetapi penyebabnya bisa berada di banyak lapisan.

Misalnya, ketika website tidak bisa dibuka, masalah belum tentu berasal dari web server. Bisa saja DNS gagal melakukan resolusi, port 80/443 tertutup firewall, service nginx atau Apache berhenti, database tidak merespons, filesystem penuh, atau bahkan server mengalami tekanan resource.

Karena itu, troubleshooting Linux Server sebaiknya tidak dilakukan dengan metode “coba-coba perintah”.

Gunakan pendekatan yang sistematis:

Observe → Identify → Verify → Fix → Validate → Monitor

Artinya, amati kondisi server terlebih dahulu, identifikasi kemungkinan penyebab, lakukan verifikasi, perbaiki masalah, pastikan layanan kembali normal, kemudian monitor agar masalah tidak berulang.

Artikel ini membahas 10 masalah Linux Server yang paling umum beserta perintah CLI yang dapat digunakan untuk melakukan diagnosis.

---

1. Disk Linux Server Penuh

Salah satu masalah paling umum adalah filesystem kehabisan ruang.

Ketika disk penuh, berbagai layanan dapat mulai bermasalah. Database mungkin gagal menulis data, aplikasi tidak dapat membuat file temporary, logging berhenti, bahkan SSH dapat mengalami perilaku yang tidak normal.

Cek penggunaan disk

Gunakan:

df -h

Contoh:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        50G   48G  1.2G  98% /

Perhatikan kolom Use%.

Jika root filesystem mencapai 90–100%, segera lakukan investigasi.

Cari direktori terbesar

sudo du -xh --max-depth=1 / | sort -h

Untuk melihat /var:

sudo du -xh --max-depth=1 /var | sort -h

Direktori yang sering menjadi penyebab:

/var/log
/var/lib/docker
/var/lib/postgresql
/var/cache
/home
/tmp

Cari file besar

sudo find / -type f -size +1G -exec ls -lh {} \; 2>/dev/null

Jangan langsung menghapus file

Kesalahan umum adalah langsung menjalankan:

rm -rf /var/log/*

Cara tersebut berbahaya karena log dapat dibutuhkan untuk investigasi dan beberapa service memiliki mekanisme logging tertentu.

Lebih baik identifikasi file atau service yang menyebabkan pertumbuhan disk.

Untuk systemd journal:

journalctl --disk-usage

Jika journal terlalu besar, pembersihan dapat dilakukan secara terkontrol:

sudo journalctl --vacuum-time=7d

Best Practice

Gunakan monitoring disk dan buat threshold alert, misalnya:

• Warning: 80%
• Critical: 90%
• Emergency investigation: 95%+

Untuk server produksi, jangan menunggu disk mencapai 100%.

---

2. RAM Habis atau Memory Usage Terlalu Tinggi

RAM yang hampir habis dapat menyebabkan aplikasi lambat, service crash, bahkan Linux mulai menggunakan swap secara agresif.

Perintah pertama:

free -h

Contoh:

               total        used        free
Mem:            16Gi        15Gi       500Mi
Swap:            2Gi       1.8Gi       200Mi

Jangan hanya melihat angka free.

Linux menggunakan RAM untuk cache sehingga angka free kecil tidak selalu berarti RAM benar-benar bermasalah.

Perhatikan available.

Melihat proses yang menggunakan RAM

top

Atau:

htop

Jika tersedia, htop biasanya lebih nyaman untuk analisis interaktif.

Dari top, tekan:

Shift + M

untuk mengurutkan proses berdasarkan penggunaan memory.

Menggunakan ps

ps aux --sort=-%mem | head

Contoh hasil:

postgres   42.5
java       28.1
node       15.7

Jika sebuah aplikasi menggunakan RAM terus meningkat, kemungkinan terjadi memory leak atau workload yang terlalu besar.

Periksa swap

swapon --show

Kemudian:

free -h

Swap bukan pengganti RAM.

Jika server terlalu sering melakukan swapping, performa dapat turun drastis.

Troubleshooting

Identifikasi:

1. Proses yang menggunakan RAM terbesar.
2. Apakah penggunaan RAM terus meningkat.
3. Apakah swap aktif.
4. Apakah ada service yang mengalami memory leak.
5. Apakah workload memang meningkat.

Jangan langsung menjalankan:

sync; echo 3 > /proc/sys/vm/drop_caches

hanya karena RAM terlihat penuh.

Linux memang menggunakan RAM sebagai cache dan biasanya akan mengelolanya secara otomatis.

---

3. CPU Mencapai 100%

CPU 100% merupakan masalah yang cukup sering ditemukan pada server aplikasi, database, container, maupun proses komputasi tertentu.

Cek:

top

Atau:

htop

Untuk melihat proses dengan CPU tertinggi:

ps aux --sort=-%cpu | head

Contoh:

PID     %CPU    COMMAND
1823    99.5    java
2941    85.2    mysqld
812     40.3    php-fpm

Apakah CPU 100% selalu buruk?

Tidak.

CPU 100% selama beberapa detik ketika server sedang melakukan pekerjaan berat bisa normal.

Yang perlu diperhatikan adalah:

• CPU tinggi dalam waktu lama.
• Load average meningkat.
• Response aplikasi menurun.
• Banyak proses masuk waiting state.
• Server mengalami timeout.

Cek load:

uptime

Contoh:

load average: 8.50, 7.90, 6.80

Interpretasi load harus mempertimbangkan jumlah core CPU.

Server 8 core dengan load 4 memiliki kondisi berbeda dengan server 2 core dengan load 4.

Investigasi proses

pidstat 1

Jika sysstat tersedia.

Atau:

top -H

untuk melihat thread yang menggunakan CPU.

Kemungkinan penyebab

CPU tinggi dapat berasal dari:

• Query database berat.
• Traffic tinggi.
• Proses backup.
• Malware atau proses tidak dikenal.
• Infinite loop aplikasi.
• Kompresi atau enkripsi.
• Container tertentu.
• Cron job.
• Proses indexing.

Jangan langsung kill -9.

Identifikasi proses dan pahami fungsi proses tersebut terlebih dahulu.

---

4. SSH Tidak Bisa Login

Masalah SSH sangat kritis karena SSH merupakan jalur utama administrasi server.

Jika SSH gagal, jangan langsung menyimpulkan service SSH mati.

Periksa dari sisi client:

ssh user@server

Gunakan mode verbose:

ssh -vvv user@server

Perintah ini membantu melihat proses koneksi berhenti pada tahap mana.

Cek konektivitas

ping SERVER_IP

Kemudian:

nc -zv SERVER_IP 22

Jika menggunakan port SSH berbeda:

nc -zv SERVER_IP 2222

Di sisi server

Periksa status SSH:

Ubuntu/Debian:

sudo systemctl status ssh

Beberapa distro menggunakan:

sudo systemctl status sshd

Periksa listening port:

sudo ss -lntp | grep :22

Periksa log

Debian/Ubuntu:

sudo journalctl -u ssh

atau:

sudo journalctl -u ssh --since "30 minutes ago"

Kemungkinan penyebab

SSH gagal login dapat disebabkan oleh:

• Service SSH berhenti.
• Port SSH berubah.
• Firewall memblokir port.
• Security group/cloud firewall memblokir.
• Password salah.
• Public key salah.
• Permission .ssh salah.
• User diblokir.
• Fail2ban memblokir IP.
• Server kehabisan resource.

Troubleshooting harus dilakukan dari layer paling dasar:

Network → Port → Service → Authentication → Authorization

---

5. Website Tidak Dapat Diakses

Website tidak bisa dibuka adalah kasus yang sering membuat sysadmin langsung memeriksa nginx atau Apache.

Padahal ada beberapa layer yang harus diperiksa.

Gunakan pendekatan:

Client
   ↓
DNS
   ↓
Network
   ↓
Firewall
   ↓
Port 80/443
   ↓
Web Server
   ↓
Application
   ↓
Database

Cek DNS

dig example.com

atau:

nslookup example.com

Cek port

nc -zv example.com 80
nc -zv example.com 443

Cek HTTP response

curl -I https://example.com

Contoh:

HTTP/2 200

Berarti endpoint HTTP merespons.

Jika:

Connection refused

kemungkinan service tidak listening.

Jika:

Connection timed out

periksa firewall, routing, network, atau security group.

Periksa web server

Nginx:

sudo systemctl status nginx

Apache:

sudo systemctl status apache2

Kemudian periksa konfigurasi.

Nginx:

sudo nginx -t

Apache:

sudo apachectl configtest

Periksa log

Nginx:

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

Apache:

sudo tail -f /var/log/apache2/error.log

Jangan hanya mengandalkan browser. Browser memberikan gejala; CLI membantu menemukan penyebab.

---

6. DNS Bermasalah

DNS merupakan salah satu komponen penting dalam infrastruktur.

Jika DNS bermasalah, server dapat terlihat seperti “internet mati” meskipun koneksi IP sebenarnya normal.

Tes:

ping 8.8.8.8

Kemudian:

ping google.com

Jika IP bisa diakses tetapi domain tidak dapat di-resolve, kemungkinan masalah berada pada DNS.

Gunakan dig

dig google.com

Untuk melihat nameserver:

dig NS example.com

Untuk melihat record tertentu:

dig A example.com
dig AAAA example.com
dig MX example.com

Periksa resolver

Pada sistem modern dengan systemd-resolved:

resolvectl status

Tes:

resolvectl query google.com

Periksa konfigurasi DNS

Tergantung distro dan konfigurasi, periksa:

cat /etc/resolv.conf

Jika menggunakan NetworkManager atau systemd-resolved, jangan sembarangan mengedit /etc/resolv.conf karena file tersebut bisa dikelola otomatis.

Konsep penting

DNS troubleshooting harus membedakan:

• DNS client.
• DNS resolver.
• DNS authoritative server.
• Record DNS.
• TTL/cache.
• DNSSEC.
• Network connectivity.

---

7. Service Gagal Start

Service gagal berjalan setelah reboot atau setelah perubahan konfigurasi merupakan masalah klasik Linux Server.

Perintah utama:

systemctl status nama-service

Contoh:

sudo systemctl status nginx

Kemudian:

sudo journalctl -u nginx

Untuk melihat log terbaru:

sudo journalctl -u nginx -n 100

Atau:

sudo journalctl -u nginx --since "10 minutes ago"

Jangan langsung restart berkali-kali

Kesalahan umum:

systemctl restart nginx
systemctl restart nginx
systemctl restart nginx

tanpa membaca error.

Lebih baik:

systemctl status nginx
journalctl -u nginx -n 100

Kemudian validasi konfigurasi:

nginx -t

Jika konfigurasi benar, baru lakukan restart:

sudo systemctl restart nginx

Periksa dependency

systemctl list-dependencies nginx

Service dapat gagal karena:

• Konfigurasi salah.
• Port sudah digunakan.
• Permission salah.
• File tidak ditemukan.
• Dependency gagal.
• Certificate expired.
• Disk penuh.
• Resource tidak mencukupi.

---

8. Permission Denied

Linux memiliki sistem permission yang sangat kuat.

Namun sistem permission yang salah dapat membuat aplikasi tidak dapat membaca atau menulis file.

Contoh:

Permission denied

Periksa:

ls -lah /path/to/file

Contoh:

-rw------- 1 root root config.php

Jika aplikasi berjalan sebagai user www-data, aplikasi tersebut mungkin tidak dapat membaca file.

Periksa user service

ps aux | grep nginx

Untuk systemd service:

systemctl cat nginx

Cari konfigurasi User= jika ada.

Periksa ownership

ls -ld /var/www/html

Kemudian:

namei -l /var/www/html/index.php

namei sangat berguna untuk melihat permission setiap bagian path.

Jangan menggunakan chmod 777 sebagai solusi

Perintah:

chmod -R 777 /var/www

memang sering membuat error permission hilang.

Tetapi itu bukan troubleshooting yang baik.

Permission seharusnya diberikan berdasarkan kebutuhan.

Contoh:

sudo chown -R www-data:www-data /var/www/html

Tetapi jangan menyalin perintah tersebut secara membabi buta. Ownership harus disesuaikan dengan arsitektur aplikasi.

Prinsipnya:

Least Privilege.

Berikan hak akses minimum yang dibutuhkan service.

---

9. Port Sudah Digunakan

Error seperti:

Address already in use

berarti aplikasi mencoba menggunakan port yang sudah digunakan proses lain.

Misalnya aplikasi ingin menggunakan port 8080.

Gunakan:

sudo ss -lntp | grep :8080

Atau:

sudo lsof -i :8080

Contoh:

java  1234  user  TCP *:8080 (LISTEN)

Sekarang kita mengetahui proses yang menggunakan port tersebut.

Periksa detail:

ps -fp 1234

Jangan langsung membunuh proses.

Cari tahu:

• Service apa?
• Mengapa berjalan?
• Apakah memang seharusnya menggunakan port tersebut?
• Apakah aplikasi baru harus menggunakan port lain?
• Apakah ada konfigurasi duplikat?

Kasus umum

Misalnya nginx gagal start karena:

bind() to 0.0.0.0:80 failed

Cari proses:

sudo ss -lntp | grep :80

Bisa saja Apache sedang menggunakan port 80.

Solusinya bukan selalu mematikan Apache. Bisa juga arsitektur diubah sehingga:

Internet
   ↓
Nginx :80/:443
   ↓
Application :8080

---

10. Server Tiba-Tiba Lambat

Server lambat adalah masalah yang paling luas karena “lambat” merupakan gejala, bukan diagnosis.

Jangan langsung restart server.

Mulailah dengan:

uptime

Kemudian:

top

Cek memory:

free -h

Cek disk:

df -h

Cek inode:

df -i

Cek proses:

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

Cek network:

ss -s

Jika tersedia:

iftop

atau:

nload

Cek I/O:

iostat -xz 1

Jangan lupa I/O

Server dengan CPU 20% belum tentu sehat.

Bisa saja storage mengalami latency tinggi.

Misalnya:

CPU: 20%
RAM: 40%
Disk utilization: 100%

Aplikasi tetap dapat terasa sangat lambat.

Inilah alasan sysadmin harus melihat beberapa resource sekaligus.

---

Pendekatan Troubleshooting Linux Server yang Sistematis

Daripada menghafalkan ratusan perintah, lebih penting memahami urutan diagnosis.

Gunakan metode berikut.

Langkah 1 — Definisikan Gejala

Tanyakan:

• Apa yang tidak bekerja?
• Kapan masalah mulai terjadi?
• Apakah semua user terdampak?
• Apakah hanya satu service?
• Apakah masalah terjadi setelah perubahan konfigurasi?

Contoh:

Website tidak dapat diakses sejak pukul 10:15 setelah konfigurasi Nginx diubah.

Informasi ini jauh lebih berguna daripada sekadar:

Server error.

Langkah 2 — Periksa Resource

Gunakan:

uptime
free -h
df -h
df -i
top

Tujuannya untuk mengetahui apakah masalah disebabkan resource exhaustion.

Langkah 3 — Periksa Service

systemctl --failed

Kemudian:

systemctl status nama-service

Langkah 4 — Periksa Port

ss -lntup

Cari apakah service benar-benar listening.

Langkah 5 — Periksa Log

Gunakan:

journalctl

atau log aplikasi.

Untuk event terbaru:

journalctl --since "30 minutes ago"

Langkah 6 — Uji dari Localhost

Jika service web bermasalah:

curl -I http://127.0.0.1

Jika localhost berhasil tetapi akses dari jaringan gagal, kemungkinan masalah berada di network atau firewall.

Langkah 7 — Uji dari Client

Misalnya:

curl -I https://server.example.com

Kemudian periksa:

ping
traceroute
nc
dig

sesuai kebutuhan.

Langkah 8 — Lakukan Perubahan Terkecil

Hindari perubahan besar ketika penyebab belum diketahui.

Prinsip yang baik:

One change → One test → Observe result.

Dengan demikian, jika terjadi perubahan perilaku, kita tahu perubahan mana yang menyebabkannya.

---

Contoh Studi Kasus

Misalnya sebuah server Ubuntu menjalankan:

Nginx
PHP-FPM
MariaDB

Tiba-tiba website tidak dapat diakses.

Daripada langsung restart semua service, lakukan:

curl -I http://127.0.0.1

Jika gagal, periksa:

systemctl status nginx

Jika Nginx aktif:

ss -lntp | grep :80

Kemudian:

nginx -t

Jika semuanya normal, cek PHP-FPM:

systemctl status php*-fpm

Kemudian database:

systemctl status mariadb

Periksa disk:

df -h

Kemudian log:

journalctl -u nginx --since "30 minutes ago"

Dengan pendekatan ini, masalah dapat dipersempit secara bertahap.

---

Cheat Sheet Troubleshooting Linux Server

Masalah	Perintah Awal
Disk penuh	df -h
Cari direktori besar	du -xh --max-depth=1
RAM tinggi	free -h
Proses RAM terbesar	ps aux --sort=-%mem
CPU tinggi	top / htop
Proses CPU terbesar	ps aux --sort=-%cpu
SSH bermasalah	systemctl status ssh
Port listening	ss -lntup
Service gagal	systemctl status service
Log service	journalctl -u service
DNS	dig domain.com
HTTP	curl -I URL
Permission	ls -lah
Path permission	namei -l path
Port bentrok	lsof -i :PORT
I/O bermasalah	iostat -xz 1
Inode habis	df -i

---

Kesalahan Troubleshooting yang Sering Terjadi

Langsung Reboot Server

Reboot memang terkadang menyelesaikan masalah sementara.

Namun reboot juga dapat menghilangkan informasi penting dari proses investigasi.

Sebelum reboot, kumpulkan:

uptime
top
free -h
df -h
systemctl --failed
journalctl -p err -b

Menghapus Log Secara Sembarangan

Log sangat penting untuk menemukan root cause.

Gunakan log rotation dan retention policy.

Menggunakan chmod 777

Ini bukan solusi universal untuk permission denied.

Cari tahu user service dan permission yang sebenarnya dibutuhkan.

Membunuh Semua Proses

Perintah seperti:

kill -9

harus menjadi pilihan terakhir, bukan langkah pertama.

Restart Semua Service

Restart semua service membuat troubleshooting semakin sulit karena terlalu banyak variabel berubah sekaligus.

Tidak Membaca Log

Pesan error biasanya memberikan petunjuk penting.

Sysadmin yang baik bukan sekadar hafal command, tetapi mampu membaca evidence.

---

Best Practice Troubleshooting Linux Server

Gunakan prinsip berikut dalam lingkungan produksi.

Pertama, selalu lakukan baseline monitoring. Ketahui kondisi normal server sebelum masalah terjadi.

Kedua, gunakan centralized logging jika infrastrukturnya sudah cukup besar.

Ketiga, dokumentasikan setiap perubahan konfigurasi.

Keempat, gunakan version control untuk konfigurasi penting.

Kelima, gunakan monitoring seperti Prometheus, Grafana, Zabbix, Icinga, atau sistem monitoring lain sesuai kebutuhan.

Keenam, buat alert untuk resource penting:

• CPU
• RAM
• Disk
• Inode
• Load average
• Network
• Service availability
• Certificate expiration

Ketujuh, gunakan prinsip least privilege.

Kedelapan, lakukan backup dan uji restore secara berkala.

Kesembilan, jangan hanya memonitor server. Monitor juga aplikasi dan dependency seperti database, DNS, storage, dan network.

Kesepuluh, dokumentasikan root cause setelah incident selesai.

---

Kesimpulan

Troubleshooting Linux Server bukan sekadar menghafal perintah seperti top, df, systemctl, atau journalctl.

Yang lebih penting adalah kemampuan berpikir sistematis.

Sepuluh masalah yang sering muncul antara lain:

1. Disk penuh.
2. RAM habis.
3. CPU 100%.
4. SSH tidak dapat login.
5. Website tidak dapat diakses.
6. DNS bermasalah.
7. Service gagal start.
8. Permission denied.
9. Port sudah digunakan.
10. Server tiba-tiba lambat.

Gunakan pendekatan:

Observe → Identify → Verify → Fix → Validate → Monitor.

Dengan pendekatan tersebut, troubleshooting menjadi lebih terukur dan risiko melakukan perubahan yang tidak perlu dapat dikurangi.

Bagi seorang sysadmin, kemampuan membaca kondisi server, memahami hubungan antarservice, menganalisis log, dan menemukan root cause merupakan keterampilan yang jauh lebih penting daripada sekadar menghafal command.

Server yang sehat bukan hanya server yang sedang “UP”, tetapi server yang dapat dipahami kondisinya, dimonitor, didokumentasikan, dan dipulihkan ketika terjadi masalah.

Frequently Asked Questions (FAQ)

Pertanyaan: Apa perintah pertama yang digunakan ketika Linux Server bermasalah?
Jawaban: Mulailah dengan uptime, top, free -h, df -h, dan systemctl --failed untuk mendapatkan gambaran kondisi server.

Pertanyaan: Bagaimana mengetahui penyebab disk Linux penuh?
Jawaban: Gunakan df -h untuk melihat filesystem yang penuh, kemudian du -xh --max-depth=1 untuk menemukan direktori yang menggunakan ruang terbesar.

Pertanyaan: Apakah CPU 100% selalu berarti server bermasalah?
Jawaban: Tidak. CPU 100% dapat normal saat workload berat. Yang perlu diperiksa adalah durasi, load average, proses penyebab, dan dampaknya terhadap layanan.

Pertanyaan: Mengapa SSH tidak bisa login ke Linux Server?
Jawaban: Penyebabnya dapat berupa masalah network, port, service SSH, firewall, authentication, permission, fail2ban, atau resource server.

Pertanyaan: Bagaimana mengetahui service Linux gagal berjalan?
Jawaban: Gunakan systemctl status nama-service, kemudian periksa detail error dengan journalctl -u nama-service.

Pertanyaan: Apa yang harus dilakukan jika muncul Permission Denied?
Jawaban: Periksa ownership, permission, user yang menjalankan service, serta permission setiap direktori pada path menggunakan ls -l dan namei -l.

Pertanyaan: Bagaimana mengetahui port sudah digunakan service lain?
Jawaban: Gunakan ss -lntup atau sudo lsof -i :PORT untuk mengetahui proses yang sedang menggunakan port tersebut.

Pertanyaan: Apakah restart server merupakan solusi troubleshooting?
Jawaban: Restart dapat mengembalikan service sementara, tetapi sebaiknya dilakukan setelah mengumpulkan informasi log dan kondisi resource agar root cause tidak hilang.

Mengelola Linux Server tidak cukup hanya mengetahui cara menjalankan command. Kemampuan membaca gejala, menganalisis resource, memahami log, memeriksa service, dan menemukan root cause adalah bagian penting dari skill seorang sysadmin.

Jika artikel ini membantu, bagikan kepada teman, rekan kerja, siswa, atau anggota tim IT yang sedang belajar Linux Server.

Punya pengalaman menghadapi disk penuh, CPU 100%, SSH error, DNS bermasalah, atau service gagal start? Tulis kasus dan solusi yang pernah Anda temukan di kolom komentar.

Jangan lupa jelajahi artikel lainnya tentang Linux Server, Ubuntu Server, Debian, CLI Linux, Networking, Monitoring, DevOps, Cybersecurity, dan System Administration untuk memperdalam kemampuan troubleshooting dan administrasi infrastruktur IT.