So probably you don’t have to do anything if you’re on a system with systemd. You can simply check the status by systemctl status tmp.mount, and double-check the unit file in /usr/lib/systemd/system/tmp.mount.
I had a /tmp issue on Fedora yesterday where imagemagick had been dumping massive files into it (it can do that if it doesn’t exit properly). I was getting /tmp “out of space” errors and thanks to your post now I know where that space comes from. Thank you. That made the foundation of the rest of this post:
Unless you want to throw some BASH together tmpwatch is pretty good as a cron entry or a systemd job. Aside from the Debian universe it has general repo availability incl’ OpenSUSE.
# Delete anything that hasn't been accessed in a day
/usr/bin/tmpwatch --atime 1d /tmp
Just make sure atime isn’t turned off for the mount, otherwise use --mtime.
> systemctl status tmp.mount
● tmp.mount - Temporary Directory /tmp
Loaded: loaded (/proc/self/mountinfo; static)
Active: active (mounted) since Wed 2021-10-27 09:36:05 EDT; 3 days ago
Tasks: 0 (limit: 4915)
Warning: some journal files were not opened due to insufficient permissions.
So, that doesn’t tell me that it is RAM disk or am I just not understanding what I am reading?
It tells you that whatever is described in the tmp.mount file, has been successfully executed.
The lines Where: /tmp and What: tmpfs tell you that at the /tmp directory you have a tmpfs (RAM disc) mounted.
I am not so concerned about the time between clearing out, so long as it does happen. It should also be noted, I do reboot this laptop about weekly, after I sudo zypper dup the thing. My biggest concern was that I was making unnecessary writes to the disk causing premature wear on the NVME.
Thanks everybody. I appreciate the input as I learned a thing or three!