Troubleshooting CodeIgniter 3: Mengatasi Session Loss Akibat Exhausted Inodes di Linux

“Pernahkah Anda mengalami kasus di mana df -h menunjukkan disk space masih lega, tapi aplikasi PHP gagal menulis session? Itulah yang terjadi pada aplikasi berbasis CI3 kami hari ini. Masalah login SSO yang persisten ternyata bukan disebabkan oleh bug pada kodingan, melainkan masalah infrastruktur server: penumpukan jutaan file session lawas yang menghabiskan jatah inodes.”

Setelah melakukan konsultasi dengan gemini, dianjurkan untuk Cek Disk Space & Inode. Hal yang selum pernah terfikir sebelumnya, dengan perintah :

# Cek sisa space
df -h

# Cek sisa inode (PENTING: seringkali disk kosong tapi inode penuh karena jutaan file session kecil)
df -i

hasil dari command tersebut

[root@repo ~]# df -h
Filesystem           Size  Used Avail Use% Mounted on
devtmpfs             1.9G     0  1.9G   0% /dev
tmpfs                1.9G     0  1.9G   0% /dev/shm
tmpfs                1.9G  8.6M  1.9G   1% /run
tmpfs                1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/mapper/cl-root   50G  2.6G   45G   6% /
/dev/sda1            976M  196M  714M  22% /boot
/dev/mapper/cl-home  439G  262G  155G  63% /var
tmpfs                379M     0  379M   0% /run/user/0
[root@repo ~]# df -i
Filesystem            Inodes    IUsed   IFree IUse% Mounted on
devtmpfs              482036      376  481660    1% /dev
tmpfs                 484957        1  484956    1% /dev/shm
tmpfs                 484957      492  484465    1% /run
tmpfs                 484957       16  484941    1% /sys/fs/cgroup
/dev/mapper/cl-root  3276800    52151 3224649    2% /
/dev/sda1              65536      355   65181    1% /boot
/dev/mapper/cl-home 29171712 19910166 9261546   69% /var
tmpfs                 484957        1  484956    1% /run/user/0

Sebagai SysAdmin atau Backend Developer, kita sering terpaku mengecek sisa hardisk dengan perintah df -h. Namun, hari ini saya belajar pelajaran mahal bahwa df -i (inodes) sama pentingnya. Gara-gara mengabaikan ‘sampah’ file session yang menumpuk hingga belasan juta file, sistem login SSO di aplikasi kami lumpuh total karena PHP timeout saat mencoba membaca direktori session.

Masalahnya bukan lagi sekadar permission, melainkan Session Junk Pile-up (Penumpukan File Session) yang ekstrem.

DIAGNOSA: Folder Session “Jebol”

Lihat output terminal Anda ini:

/dev/mapper/cl-home 29171712 19910166 9261546 69% /var drwxrwx---. 2 root apache 1065357312 Nov 20 11:54 /var/lib/php/session

Kesimpulan: Ada jutaan (mungkin belasan juta) file session sampah di dalam folder tersebut. PHP mengalami timeout saat mencoba mencari (read) atau menulis (write) file session baru di antara tumpukan sampah tersebut, sehingga session yang terbentuk kosong.

Inode Usage Tinggi: Partisi /var menggunakan 19.9 Juta file (inodes).

Ukuran Folder Tidak Wajar: Ukuran directory entry /var/lib/php/session itu sendiri adalah 1 GB (1065357312 bytes). Ini bukan ukuran total file di dalamnya, tapi ukuran “daftar isi” foldernya saja.


LANGKAH PERBAIKAN (Lakukan Berurutan)

1. Rotasi Folder Session (Solusi Tercepat)

Jangan mencoba menghapus file dengan rm -rf * di folder itu, server akan hang karena terlalu banyak file. Lakukan teknik Rename & Replace:

Jalankan perintah ini di terminal sebagai root:

# 1. Pindahkan folder session yang penuh sampah ke nama lain (agar sistem tidak membacanya lagi)
mv /var/lib/php/session /var/lib/php/session_OLD

# 2. Buat folder session baru yang bersih
mkdir /var/lib/php/session

# 3. Set permission yang benar (PENTING)
chown apache:apache /var/lib/php/session
chmod 770 /var/lib/php/session

# 4. Restart Web Server
systemctl restart httpd

Catatan: Setelah sistem normal kembali, Anda bisa menghapus folder session_OLD di background nanti (ini akan memakan waktu lama).

Setelah melakukan jurus ‘rename & replace’ pada folder session dan merestart Apache, momen kebenaran pun tiba. Saya mencoba login kembali, dan… voila! Debug bar yang tadinya hanya menampilkan array kosong, kini penuh dengan data user lengkap mulai dari id, username, hingga level. Masalah yang sempat membuat panik setengah hari ternyata selesai dalam 5 menit pembersihan sampah. Pelajaran hari ini: Terkadang solusi bukan ada di baris kode, tapi di kebersihan server.Setelah melakukan jurus ‘rename & replace’ pada folder session dan merestart Apache, momen kebenaran pun tiba. Saya mencoba login kembali, dan… voila! Debug bar yang tadinya hanya menampilkan array kosong, kini penuh dengan data user lengkap mulai dari id, username, hingga level. Masalah yang sempat membuat panik setengah hari ternyata selesai dalam 5 menit pembersihan sampah.

Pelajaran hari ini: Terkadang solusi bukan ada di baris kode, tapi di kebersihan server.

Leave a Reply

Your email address will not be published. Required fields are marked *