DEV Community: Fajar Trengginas

Infra Learning Journey #3 – Filesystem & Disk Debugging

Fajar Trengginas — Fri, 27 Feb 2026 16:41:13 +0000

Catatan Belajar Hari Ketiga Memahami Disk Usage, Inode, dan Debugging Error “No Space Left on Device”

Setelah memahami process dan signal di hari sebelumnya, saya masuk ke salah satu penyebab klasik server production down: masalah filesystem dan disk.

Hari ini saya belajar bahwa error seperti:

No space left on device

Tidak selalu berarti disk benar-benar penuh.

1️⃣ `df` vs `du` — Jangan Sampai Salah Paham

Untuk melihat penggunaan disk secara global:

df -h

-h = human readable

Menampilkan penggunaan disk per filesystem
Contoh output:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       50G   45G   3G   94%  /

Jika Use% mencapai 100%, disk block habis.

Untuk melihat ukuran folder tertentu:

du -sh *

Atau untuk melihat folder terbesar:

du -h --max-depth=1 | sort -hr

Perbedaan penting:

df → melihat penggunaan disk dari sisi filesystem
du → melihat ukuran file/folder dari sisi direktori

2️⃣ Inode: Penyebab Tersembunyi “Disk Penuh”

Saya belajar bahwa setiap file di Linux menggunakan inode.

Cek inode dengan:

df -i

Contoh:

Filesystem     Inodes   IUsed   IFree IUse% Mounted on
/dev/sda2     3276800 3276800      0  100% /

Jika inode 100%, maka:

Tidak bisa membuat file baru
Akan muncul error:

No space left on device

Meskipun df -h masih menunjukkan sisa storage

Ini sering terjadi jika ada terlalu banyak file kecil seperti:

Log file
Cache
Temporary file

Upload kecil dalam jumlah besar

3️⃣ Simulasi Inode Penuh
Untuk memahami ini, saya membuat ribuan file kecil:

mkdir inode-test
cd inode-test

for i in {1..50000}; do touch file_$i.txt; done

Lalu cek:

df -i

Terlihat bahwa inode usage meningkat drastis.

Ini membuka wawasan bahwa disk penuh bukan hanya soal ukuran file.

4️⃣ Mount Point Awareness

Saya juga belajar mengecek mount point:

lsblk

atau

mount | grep '^/dev'

Mount	Fungsi
`/`	Root filesystem
`/home`	Data user
`/var`	Log dan data service
`/tmp`	File sementara

Jika /var penuh, service seperti database atau web server bisa gagal berjalan.

5️⃣ Kenapa df dan du Bisa Berbeda?

Kasus nyata di production:

df -h menunjukkan 100%

du tidak menunjukkan file besar

Kemungkinan penyebabnya:

File sudah dihapus tetapi masih digunakan oleh process

Linux tidak benar-benar membebaskan space sampai process yang memegang file descriptor menutup file tersebut

Untuk mengecek:

lsof | grep deleted

Ini adalah teknik debugging yang sangat penting di server production.

6️⃣ Mini Simulasi Log Growth

Saya menjalankan fake service dan mengarahkan output ke file:

./fake-service.sh >> service.log &

Kemudian memantau ukuran file:

du -sh service.log

Dari sini saya memahami bagaimana log bisa tumbuh tanpa disadari dan menyebabkan disk penuh jika tidak ada log rotation.

💡 Insight Hari Ini

Error:

No space left on device

Tidak selalu berarti:

RAM habis
CPU overload
Database error

Sering kali penyebabnya adalah:

Disk block habis
Inode habis
File descriptor masih terbuka

Memahami filesystem membuat saya melihat sistem Linux dengan cara yang jauh lebih dalam lagi.

Sampai jumpa di Infra Journey hari keempat nanti!

Infra Learning Journey #2 – Process dan Signal di Linux

Fajar Trengginas — Thu, 26 Feb 2026 16:45:28 +0000

Catatan Belajar Hari Kedua Memahami Process Linux dan Signal Handling

Setelah memahami permission dan log processing di hari pertama, saya mulai masuk ke konsep yang jauh lebih penting dalam sistem Linux: process management.

Hari ini saya belajar bagaimana sebuah service berjalan, bagaimana Linux mengelola process, dan bagaimana signal bekerja saat kita menghentikan program.

1️⃣ Apa Itu Process?

Setiap command yang dijalankan di Linux adalah sebuah process.

Contoh sederhana:

sleep 300

Saat command ini berjalan, Linux membuat sebuah process dengan PID (Process ID) unik.

Untuk melihatnya:

ps aux | grep sleep

Dari sini saya memahami bahwa:

Setiap aplikasi adalah process dan Setiap process punya PID

Linux mengelola semuanya melalui process tree

2️⃣ Background Process & Job Control

Menjalankan command di background:

sleep 300 &
jobs

Ternyata jobs hanya menampilkan process yang dijalankan di session shell yang sama.Jika membuka terminal baru, jobs tidak akan menampilkan apa pun.

Ini membuat saya memahami bahwa job control bersifat lokal terhadap shell session.

3️⃣ Parent & Child Process

Saya membuat simulasi service sederhana:

#!/bin/bash

while true
do
    echo "Service running at $(date)"
    sleep 2
done

Ketika dijalankan:

./fake-service.sh &

Saya menemukan sesuatu yang menarik:

Script memiliki satu PID

sleep memiliki PID berbeda

PID sleep akan terus berubah

Kenapa?

Karena:

Script adalah parent process

Setiap sleep adalah child process

Saat sleep selesai, loop membuat child baru dan penting untuk diketahui jika :

Killing child process tidak menghentikan service
Killing parent process menghentikan semuanya

4️⃣ Killing Process: kill vs pkill

Untuk menghentikan process berdasarkan PID:

kill <PID>

Untuk menghentikan berdasarkan nama:

pkill sleep

Perbedaannya:

kill → target spesifik PID

pkill → target berdasarkan nama process

5️⃣ Signal Handling: SIGTERM vs SIGKILL

Default:

kill PID

Sebenarnya mengirim:

SIGTERM (15)

Force kill:

kill -9 PID

Mengirim:

SIGKILL (9)

Perbedaan penting:

Signal	Graceful	Bisa Ditangkap
SIGTERM	Ya	Ya
SIGKILL	Tidak	Tidak

Untuk memahami graceful shutdown, saya menambahkan trap:

trap "echo 'Service stopping...'; exit 0" SIGTERM

Saat dikill dengan SIGTERM, service bisa membersihkan dirinya sebelum berhenti.

Konsep ini sangat penting dalam container dan production system.

💡 Insight Penting Hari Ini

Docker container pada dasarnya adalah Linux process yang diisolasi.

Jika main process mati, container mati.

Jika signal tidak ditangani dengan benar, shutdown bisa tidak graceful.

Memahami process dan signal membuat saya melihat Docker bukan sebagai “magic”, tetapi sebagai abstraction di atas Linux process.

Sampai jumpa di Infra Journey hari ketiga!

Infra Learning Journey #1 – Dasar Linux CLI: Permission & Log

Fajar Trengginas — Thu, 26 Feb 2026 13:16:06 +0000

Hari Pertama perjalanan saya belajar infrastruktur akhirnya dimulai. Selama ini, interaksi saya dengan Linux mungkin sama seperti kebanyakan orang: copy-paste command dari StackOverflow dan berharap semuanya berjalan lancar.

Tapi kali ini target yang saya inginkan berbeda. Saya tidak mau hanya sekadar tahu command; saya ingin benar-benar memahami bagaimana sistem linux ini bekerja. Dan ternyata, hari pertama ini penuh dengan momen "Ohhh, seperti itu!"

Ini adalah suatu proses yang bakal merubah cara pandang saya terhadap terminal Linux.

Momen "Aha!" Tentang Permission (Bukan Lagi Sebuah Angka Random)

Dulu, setiap kali ada error permission denied, jurus andalan saya (dan mungkin kalian juga) adalah mengetik chmod 777. Saya hanya tahu angka 755 atau 644 tanpa mengerti maknanya.

Ternyata, itu bukan angka random. Permission di Linux menggunakan sistem bitmasking yang sangat logis:

r (read) = 4

w (write) = 2

x (execute) = 1

Jadi, angka-angka sakti itu hanyalah hasil penjumlahan:

7 = 4 + 2 + 1 (Artinya bisa read, write, execute)

5 = 4 + 1 (Artinya bisa read & execute, tanpa write)

6 = 4 + 2 (Artinya bisa read & write, tanpa execute)

Satu insight penting yang baru saya sadari: Saya baru paham bahwa sebuah Folder mutlak membutuhkan permission x (execute) agar bisa diakses (di-enter menggunakan cd). Tanpa x, walaupun folder tersebut punya permission r (read), kita tetap tidak akan bisa masuk ke dalamnya!

Pipe (|) Itu Bukan Sekadar Pemisah, Tapi Jembatan

Awalnya saya berpikir simbol | (pipe) fungsinya hanya untuk memisahkan dua command agar rapi. Salah besar.

Ternyata, pipe berfungsi menangkap output dari command pertama, lalu menjadikannya input untuk command berikutnya.

Contoh sederhananya seperti ini:

grep ERROR logs/app.log | wc -l

Cara membacanya sangat mengalir: "Cari kata ERROR di file log, lalu lempar hasilnya ke command wc -l untuk dihitung jumlah barisnya."

Mempelajari CLI Linux itu rasanya seperti bermain Lego. Command-command kecil yang terlihat sederhana bisa digabungkan menjadi alat yang sangat powerful.

Membuat Mini Log Analyzer

Untuk mempraktikkan ilmu "Lego" tadi, saya mencoba menganalisis file log sederhana. Katakanlah kita punya isi log seperti ini:

INFO Server started ERROR Database failed WARNING Disk almost full ERROR Connection timeout INFO User login

Saya ingin tahu: Ada berapa banyak sih pesan INFO, WARNING, dan ERROR di log tersebut?

Command yang saya pakai adalah:

grep -oE "INFO|WARNING|ERROR" logs/app.log | sort | uniq -c

Kenapa harus di-sort dulu? Kenapa tidak langsung ke uniq? Ini insight kecil tapi sangat krusial dalam log processing. Command uniq ternyata hanya bisa mendeteksi duplikat jika barisnya bersebelahan. Jadi, kita harus mengurutkannya (sort) terlebih dahulu agar log yang sama berkumpul, barulah dihitung (uniq -c).

Rekap Perjalanan Minggu Pertama

Jika dirangkum, ini bekal berharga yang saya dapatkan minggu ini:

Permission adalah logika bitmask, bukan hafalan nomor telepon.

Folder butuh akses x (execute) untuk bisa dimasuki.

Log processing adalah skill dasar (dan sangat menyenangkan!) untuk seorang DevOps/SysAdmin.

CLI bisa menjadi senjata yang sangat powerful jika kita paham cara merangkainya.

Ini baru hari pertama, tapi saya sudah merasa jauh lebih nyaman menatap layar hitam terminal. Perjalanan menuju Mastering Infrastructure masih sangat panjang, tapi satu hal yang pasti: Pondasi CLI saya mulai terbentuk.

Sampai jumpa di Infra Journey hari kedua!