Debug Nginx Pakai strace (Jarang Banget Dibahas)

Saat Nginx bermasalah, biasanya orang:

• Cek error.log
• Naikkan log_level debug
• Restart service

Masalahnya:

Ada kelas bug yang tidak pernah muncul di log Nginx.

Contoh:

• File ada tapi selalu 404
• Permission terlihat benar tapi tetap gagal
• Socket upstream “kadang” connect, kadang tidak
• Nginx diam, tapi request timeout

Di sinilah strace jadi senjata terakhir.

---

1. Apa Itu strace?

strace adalah tool Linux untuk:

• Memonitor system call
• Melihat apa yang dilakukan process ke kernel

Artinya:

Kita melihat Nginx bicara langsung ke OS

Bukan asumsi. Bukan log internal. Fakta mentah.

---

2. Kapan strace Dibutuhkan?

Gunakan strace jika:

• Log Nginx kosong tapi error nyata
• Permission terasa “benar”
• Ada masalah filesystem, socket, DNS
• Bug hanya muncul di production

⚠️ Jangan pakai strace terus-menerus di production tanpa alasan.

---

3. Menentukan Process Nginx yang Tepat

Nginx terdiri dari:

• 1 master process
• Banyak worker process

Biasanya:

• Worker yang perlu di-trace

Cari PID:

ps aux | grep nginx

Atau:

pidof nginx

---

4. strace Dasar (Attach ke Worker)

strace -p <PID>

Langsung terlihat:

• open()
• read()
• write()
• connect()
• stat()

Tekan Ctrl+C untuk berhenti (process tidak mati).

---

5. Kasus Nyata #1: File Ada Tapi 404

Konfigurasi tampak benar. File ada.

Gunakan:

strace -p <PID> -e trace=open,stat

Output contoh:

stat("/var/www/html/index.html", 0x7ffc...) = -1 ENOENT

Artinya:

• Nginx mencari file di path berbeda
• Biasanya karena:
  • Salah root
  • Salah alias

Tanpa strace, ini sulit dilihat.

---

6. Kasus Nyata #2: Permission “Sudah Benar” Tapi Gagal

Error log:

permission denied

Gunakan:

strace -p <PID> -e trace=open

Output:

open("/var/www/html/app/cache", O_RDONLY) = -1 EACCES

Lalu:

open("/var/www/html/app", O_RDONLY) = 13

Insight penting:

• Parent directory tidak executable (x)
• Bukan file-nya yang salah

Ini tidak jelas di log Nginx.

---

7. Kasus Nyata #3: Upstream Kadang Timeout

strace -p <PID> -e trace=connect

Output:

connect(12, {sa_family=AF_INET, sin_port=9000}, ...) = -1 ECONNREFUSED

Artinya:

• PHP-FPM / backend benar-benar menolak
• Bukan Nginx lambat

Atau:

connect(...) = -1 ETIMEDOUT

Berarti:

• Network
• Firewall
• Backend overload

---

8. Debug DNS Resolver (Jarang Disadari)

Jika pakai hostname di proxy_pass:

proxy_pass http://api.internal;

Gunakan:

strace -p <PID> -e trace=network

Cari:

• getaddrinfo()
• sendto() ke DNS

Masalah umum:

• DNS lambat
• Resolver salah
• TTL habis

---

9. strace + Output ke File (Wajib untuk Analisis)

strace -p <PID> -o /tmp/nginx.strace -tt

Keuntungan:

• Timestamp presisi
• Bisa dianalisis ulang
• Bisa di-grep

---

10. Fokus ke System Call Penting

Tidak perlu lihat semuanya.

Filter yang berguna:

• open, stat, access
• connect, accept
• read, write
• sendfile
• futex (thread lock)

Contoh:

strace -p <PID> -e trace=open,connect,stat

---

11. Performance Issue: Bukan Selalu Nginx

Jika lihat:

futex(..., FUTEX_WAIT, ...)

Artinya:

• Worker menunggu lock
• Bisa karena:
  • Disk I/O lambat
  • Cache lock
  • Upstream lambat

---

12. Peringatan Penting (WAJIB Dibaca)

• strace memperlambat process
• Jangan trace semua worker
• Gunakan sesingkat mungkin
• Jangan lupa detach

Best practice:

Trace 1 worker, 1 kasus, 1–2 menit

---

13. strace vs nginx debug log

Debug Log	strace
Log internal	System call nyata
Perlu reconfig	Tidak
Verbose	Brutal
Aman	Lebih berisiko

Gunakan debug log dulu.
strace adalah langkah terakhir.

---

14. Checklist Debug Nginx dengan strace

1. Tentukan worker PID
2. Tentukan symptom
3. Filter system call
4. Capture singkat
5. Analisis path / errno
6. Fix config, bukan asumsi

---

15. Kesimpulan

strace:

• Bukan tool sehari-hari
• Tapi penyelamat saat semua log bohong

Kalimat kuncinya:

Jika Nginx diam, dengarkan kernel.