I have a system configured with LUKS-encrypted ext4 filesystems on LVM volumes. I want to reduce the size of the filesystem mounted on /tmp (to free up space so I can grow the /var filesystem). I thought that once I unmounted /tmp I’d be able to reduce the filesystem with resize2fs. However, even after unmounting /tmp I get the following:
sudo resize2fs /dev/mapper/luks-[tmp] 500M
resize2fs: Device or resource busy while trying to open /dev/mapper/luks-[tmp]
Using fuser and lsof I find no processes accessing /dev/mapper/luks-[tmp].
How can I identify what process(es) are blocking me from resizing this filesystem?
Usually this type of resizing is easier to do from a live usb image not the running system.
Also surprised that you have /tmp on a separate partitions, that is unusual custom setup.
Perhaps, but given that the filesystem is on an LVM volume and I was able to unmount it, a reduce while the system is running should be possible to do.
Putting /tmp in its own filesystem is a personal preference, admittedly probably influenced by recommendations and Linux installer defaults from 20+ years ago. I figure having /tmp on its own filesystem helps manage disk space usage and ensures that temporary files don’t unexpectedly impact the amount of storage available for other uses such as /home and /usr.
My install is not configured that way; /tmp is LUKS on top of LVM as described in the subject line:
$ mount|grep luks/dev/mapper/luks-<redacted-var> on /var type ext4 (rw,relatime,seclabel)
/dev/mapper/luks-<redacted-tmp> on /tmp type ext4 (rw,relatime,seclabel)
/dev/mapper/luks-<redacted-home> on /home type ext4 (rw,relatime,seclabel)
There is a /dev/mapper/fedora-tmp that represents the LVM volume on which LUKS filesystem resides.
That’s true of ordinary partitions, but I’ve done online resizes (usually grows) of filesystems on LVM volumes routinely for over 15 years, including ones with LUKS encryption like the case I’m dealing with here. I have never observed any data loss or corruption from doing so. The only times I’ve seen it fail is when the underlying physical volume is full (in which case LVM simply refuses to execute the resize, again without any data loss or corruption). In my understanding shrinking should be possible (and safe) as well, as long as the filesystem is unmounted first (and in this case the filesystem in question is /tmp so the risk is even lower).
I checked another system that was installed more recently and was configured closer to current defaults, but it looks like I configured that one with /tmp on a physical disk too:
$ mount|grep /tmp
/dev/sda3 on /tmp type btrfs (rw,relatime,seclabel,compress=zstd:1,space_cache=v2,subvolid=258,subvol=/tmp)
I might add that one of the main reasons for having /tmp be a virtual file system is for security. Many apps create files in /tmp and when in ram a shutdown or reboot wipes that out cleanly. When /tmp resides on a disk anything that is written to that space remains for potential forensic analysis and can present a security issue if the system may be hacked.
That’s a good point. That kind of security concern is the reason I encrypted my /tmp partition but it’s true it can persist through a reboot. Perhaps I should consider moving my /tmp to RAM instead (though there is a question of how it impacts memory usage; this system has only 16 GB which I easily fill up under normal use).
I got the filesystem resized from a live usb image as you suggested. Still puzzled as to why it didn’t work from the running system given the filesystem was unmounted, but doing the operation offline achieved my objective.