Apakah rekan-rekan pernah coba menghapus logical volume (LV) di LVM tapi tidak bisa karena dianggap masih dalam keadaan mounting? Padahal sudah tidak mounting, sudah dicek pakai lsof juga tidak ada proses yang ter-reference ke LV tersebut, bahkan lsblk juga sudah tidak ada mount point-nya.
Kemarin saya mengalami error sejenis di salah satu server klien berbasis Rocky Linux 8 saat hendak menghapus LV /dev/rl/var_tmp. Meskipun sudah tidak ada aktivitas, setiap kali saya mau lvremove, muncul pesan error berikut:
Logical volume rl/var_tmp contains a filesystem in use.
Berikut adalah beberapa tahapan troubleshooting yang saya lakukan, mulai dari cara standar yang paling basic sampai cara yang lumayan advance sampai ketemu penyebab dan solusinya seperti apa.
Awalnya, saya disable proses auto-mount LV tersebut dengan cara melakukan comment melalui file /etc/fstab, berikut isi filenya setelah saya edit:
/dev/mapper/rl-root / xfs defaults 0 0 UUID=ce99ae8c-7225-4117-8403-e9d4079989dd /boot xfs defaults 0 0 UUID=9799-DA28 /boot/efi vfat umask=0077,shortname=winnt 0 2 /dev/mapper/rl-dev_shm /dev/shm xfs defaults 0 0 /dev/mapper/rl-home /home xfs defaults,nodev,nosuid 0 0 /dev/mapper/rl-tmp /tmp xfs defaults,nodev,noexec,nosuid 0 0 /dev/mapper/rl-var /var xfs defaults,nodev,nosuid 0 0 /dev/mapper/rl-var_log /var/log xfs defaults,nodev,noexec,nosuid 0 0 /dev/mapper/rl-var_log_audit /var/log/audit xfs defaults,nodev,noexec,nosuid 0 0 #/dev/mapper/rl-var_tmp /var/tmp xfs defaults,nodev,noexec,nosuid 0 0 /dev/mapper/rl-swap none swap defaults 0 0 /dev/mapper/zimbra-general /opt/zimbra xfs defaults 0 0
Kemudian saya juga sempat cek status mount menggunakan lsblk --fs. Dari hasil perintah tersebut, padahal baris rl-var_tmp pada kolom MOUNTPOINT sudah kosong:
# lsblk --fs NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 vfat 9799-DA28 /boot/efi ├─sda2 xfs ce99ae8c-7225-4117-8403-e9d4079989dd /boot └─sda3 LVM2_member gthCLD-ziL5-CJNw-WNOn-dUN8-7L12-w24dEa ├─rl-root xfs e5425615-52f0-4831-a4a8-bdf7bccd53e1 / ├─rl-swap swap 4a942568-d306-4250-8fa8-0c3e58594f82 [SWAP] ├─rl-dev_shm xfs 2bd30f6f-980b-440a-b4d3-6fe93e710ba0 /dev/shm ├─rl-var_tmp xfs e388ad7e-4294-4bdf-bfa0-e22f9a9cfe14 ├─rl-var_log xfs fa11008d-45fc-42bd-b113-165200c6f9fb /var/log ├─rl-home xfs e12599df-fb3d-4710-b21d-48fcd74a1b9b /home ├─rl-var xfs eabf7c55-4cc1-4d5d-aec0-0f6219e5e23c /var ├─rl-var_log_audit xfs b0f2b272-59ac-4ad4-a314-048d71964144 /var/log/audit └─rl-tmp xfs 75ec97f5-cb8d-4652-93e0-6fdde8151e8d /tmp sdb └─sdb1 LVM2_member qYzgzg-b6qk-Vk6z-KQrx-srwR-ncb0-gK5puZ └─zimbra-general xfs 21d01a33-393b-4469-a9a6-9740d5611dc3 /opt/zimbra
Secara normal, jika MOUNTPOINT kosong berarti bisa dihapus. Namun tetap tidak bisa dengan pesan error yang sama. Selain itu saya juga mencoba beberapa perintah pengecekan yang bisa saya gunakan sebelumnya:
-
lsof | grep var_tmp: Ini perintah untuk cek apakah masih ada proses yang ter-reference ke LV tersaebut. Hasilnya, tidak muncul apapun -
fuser /dev/rl/var_tmp: Ini perintah untuk cek apakah masih ada user yang masih berada atau menggunakan direktori tersebut. Hasilnya, tidak muncul apapun -
umount -fl /dev/rl/var_tmp: Ini perintah untuk force unmount LV dari sistem. Perintah ini sukses, tapi pada saatlvremovetetap muncul pesan error yang sama -
dmsetup remove -f rl-var_tmp: Ini perintah untuk force remove device mapper dari kernel Linux. Hasilnya, tetap tidak berhasil dengan pesan errorDevice or resource busy. Dari perintah ini, ternyata benar LV tersebut masih ter-mounting di kernel
Dari hasil perintah dmsetup, saya baru tahu bahwa Linux terbaru seperti Redhat 8+, Rocky 8+ Alma beserta dengan turunannya ada fitur Mount Namespaces. Suatu service biasanya membuat copy mount table sendiri saat startup. Jadi meskipun sudah kita unmount, service tertentu mungkin masih ter-reference ke disk tersebut di namespace service tersebut. Akhirnya saya coba melakukan pengecekan mount table di kernel Linux dengan perintah berikut:
# grep "rl-var_tmp" /proc/*/mounts /proc/1178/mounts:/dev/mapper/rl-var_tmp /var/tmp xfs rw,seclabel,nosuid,nodev,noexec...
Nah dari hasil tersebut, ternyata LV memang masih digunakan oleh proses dengan PID 1178. Setelah dicek dengan ps aux | grep 1178, ternyata service yang dimaksud adalah chronyd yang digunakan untuk sinkronisasi NTP.
# ps aux | grep 1178 chrony 1178 0.0 0.0 140180 3920 ? S 2025 2:02 /usr/sbin/chronyd
Selanjutnya berarti tinggal stop service chronyd lalu coba lvremove lagi:
# systemctl stop chronyd # lvremove /dev/rl/var_tmp Do you really want to remove active logical volume rl/var_tmp? [y/n]: y Logical volume "var_tmp" successfully removed.
Setelah LV tersebut berhasil dihapus, service chronyd bisa di start lagi:
# systemctl start chronyd # systemctl status chronyd ● chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2025-08-21 09:19:45 WIB; 4 months 25 days ago Docs: man:chronyd(8) man:chrony.conf(5) Main PID: 1178 (chronyd) Tasks: 1 (limit: 100430) Memory: 1.6M CGroup: /system.slice/chronyd.service └─1178 /usr/sbin/chronyd
Sekarang rekan-rekan bisa cek list LV dengan perintah lvremove, seharusnya LV yang dimaksud sudah tidak ada:
# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert dev_shm rl -wi-ao---- 10.00g home rl -wi-ao---- 14.41g root rl -wi-ao---- 70.00g swap rl -wi-ao---- 10.00g tmp rl -wi-ao---- 5.00g var rl -wi-ao---- 10.00g var_log rl -wi-ao---- 10.00g var_log_audit rl -wi-ao---- 5.00g general zimbra -wi-ao---- <3.00t
Namun apabila rekan-rekan ragu untuk melakukannya, Excellent juga menyediakan layanan implementasi & maintenance sistem operasi Red Hat Enterprise Linux (RHEL) dan sudah mencakup apabila dibutuhkan proses penghapusan tersebut. Bagi rekan-rekan yang berminat untuk jasa layanan tersebut bisa langsung kontak & tanya-tanya ke email sales@aktiva.co.id.