I’ve been wondering why my /tmp directory was so full and just noticed that CLEAR_TMP_DIRS_AT_BOOTUP doesn’t work in systemd. I don’t know if it has been mentioned already. I just rebooted in system V and /tmp is empty now. Maybe /etc/sysconfig/cron is not used at all.
I created the file /etc/tmpfiles.d/tmp.conf with the following content:
# This file overwrites systemd defaults in /usr/lib/tmpfiles.d/tmp.conf
# **See tmpfiles.d(5) for details**
# Clears /tmp and /var/tmp and creates /tmp/.cache
D /tmp 1777 root root 1s
D /var/tmp 1777 root root 1s
d /tmp/.cache 1777 root root 1s
Notice that I instructed it to create the directory /tmp/.cache in the last line, because I need this directory. In System V, I’m still using ugly commands to do this.
CLEAR_TMP_DIRS_AT_BOOTUP is ignored by systemd but systemd-tmpfiles achieves the same thing. All I did was overwrite the defaults in /usr/lib/tmpfiles.d/tmp.conf:
# This file is part of systemd.
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
# See tmpfiles.d(5) for details
# Clear tmp directories separately, to make them easier to override
d /tmp 1777 root root 10d
d /var/tmp 1777 root root 30d
The “workaround” you suggested on your blog is just other way to deal with temporary files. If you’re not writing anything in /tmp on the filesystem, obviously you don’t need to clear anything.
There are files created in “/tmp”, even if not directly by me. Some of these are reused after a reboot. Some of them are deleted when the application shuts down. But some of them have random names, are not deleted when the application shuts down, and thus accumulate.
I originally started using “tmpfs” for “/tmp” because that way, together with encrypted swap, I could reduce the problems of unencrypted data being left behind on the disk. That’s no longer as important, since I am using an encrypted LVM with the effect that the root file system is encrypted.
On 01/03/2012 07:56 PM, nrickert wrote:
> Some of these are reused after a reboot.
maybe, but the ‘convention’ (as i understand it) is that anything of a
temporary nature which should persist after a boot is be directed (by
the program developer) to /var/tmp/, and nothing in /tmp should be
expected to remain though a boot…
If you use RAM instead of filsesystem for /tmp, there is nothing to clear in /tmp at boot because there is nothing left when you reboot. I thought it was obvious enough. But you know that already. So what was the point of explaining to us that /tmp gets filled with random files under Linux? Are you suggesting we never noticed?
systemd does not follow the documented actions concerning /tmp files at boot time, whereas the predecessor systemv adheres to these standards
temporary (F5, change to systemv) allows for clenup of /tmp
There are several novel and imaginative circumventions to resolve the problem, most likely beyond the ken of novice users
What is the resolution to the problem ? I have booted with systemv, and /tmp is cleared as expected. Although the boot process is a bit longer, systemv does offer the presence of /var/log/boot.msg as well as more verbose boot detail(s). The availability of this log, alone, is worth the boot override to systemv. The lack of adherence to documented boot parameters is usually (and unfortunately) resolved by simply revising said documentation. I do hope such an easy path is not the solution.
My reading of the man page for “tmpfiles.d” is that the “D” indicates that the directory should be emptied. So I tried that.
I commented out my fstab entry for a tmpfs mount. I copied “tmp.conf” to “/etc/tmpfiles.d” and then changed the “d” to a “D” for the entry for “/tmp”. Then I rebooted.
That was yesterday afternoon. A check showed that “/tmp” was the plain directory, part of the root file system, and that it only had new files. Well, that’s no test because “/tmp” was already empty.
I booted again this morning. Again, it had only new files. There was nothing left behind from yesterday. And some of the files that I saw yesterday were ones that I expected to see left around if “/tmp” was not cleared.
Thus far, it supports my reading. The “D” flag is the important one for clearing on boot. The time indicator on that line is only there to satisfy the syntax requirements for lines in that file.
I’ll continue to monitor that over the next few reboots. After that, I may go back to using tmpfs.
I think CLEAR_TMP_DIRS_AT_BOOTUP is one of the bugs fixed in the most recent systemd update, glancing at the changelog. Another is /etc/sysconfig/kernel:MODULES_LOADED_AT_BOOT I think. But I’ve reverted to sysvinit for other reasons.
The /etc/tmpfiles.d/tmp.conf I posted is a acceptable workaround. The only problem is that it doesn’t reflect the settings in /etc/sysconfig/cron. So the fix is probably to get the list of directories based on (LONG)TMP_DIRS_TO_CLEAR and time based on MAX_DAYS_IN(LONG)TMP and pass it or not to systemd-tmpfiles depending on the value of CLEAR_TMP_DIRS_AT_BOOTUP. Maybe that’s what they did, as @ken_yap mentioned they got it fixed.