In unix, it is traditional for some software and scripts to save temporary data in files either in “/tmp” or in “/var/tmp”. Remembering back to earlier times, the unix startup scripts would first run a command to save edit recovery files that might have been left over from a system crash. Then they would delete everything in “/tmp”. This was done in the early stages of booting before any running software might create a temporary file.
Files in “/var/tmp” were not normally cleared on boot. However, a regular cron job would typically delete stale files in “/tmp” and “/var/tmp”, where “stale” meant not used for some period. The system administrator could tweak the cron jobs.
The tradition that has developed, is that files saved in “/tmp” are likely to disappear at the next boot. Files saved in “/var/tmp” are persistent across reboots, but could be deleted when they are sufficiently stale.
The current controversy
In openSUSE, there is a variable CLEAR_TMP_DIRS_AT_BOOTUP defined in “/etc/sysconfig/cron” which, if set to “yes”, is supposed to result in “/tmp” being cleared during boot. With the switch to using “systemd” in openSUSE 12.1, this configuration parameter is now being ignored. This has been reported as Bug 721682. The question, is what to do about it.
I’m only an openSUSE user, so I don’t have any special input. But clearly there’s an interest in alternatives. Feel free to comment here if you have ideas, especially if you don’t want to sign up at the Bugzilla site.
Note that this is not an actual problem for most users. It is only a problem for people running software that leaves so much lying around in “/tmp” that it needs to be forcibly cleared. It isn’t an actual problem for me, though I do prefer to keep “/tmp” clean enough that I can see what is there.
I have started imitating what solaris has done for a number of years – at least since solaris 7, probably earlier. That is, “/tmp” is allocated from temporary space, which makes it a kind of ram disk. People talk of this as mounting “/tmp” from swap. This worked pretty well when I was administering some solaris systems. On those systems available for public access, I would mount “/tmp” with a limit of 100M of space. That way, if a student filled up “/tmp” with a runaway program, he wouldn’t be killing all available memory.
With openSUSE, I started mounting “/tmp” from swap in version 11.4. I did this on systems where I used an encrypted swap partition. I described that in a blog post on disk encryption. My main reason, at that time, was that temporary copies of sensitive data can show up in “/tmp” and I don’t want that written unencrypted to disk. I did not mount “/tmp” from swap on the system where openSUSE was installed in an encrypted LVM. In retrospect, that was probably a poor decision. If I mount “/tmp” as tempfs, then the data would not have to be encrypted unless swapped out to disk, whereas having “/tmp” part of the encrypted LVM required that it always be encrypted. So using tmpfs would slightly reduce the encryption cost with no actual loss of privacy and security.
With the current failure to honor CLEAR_TMP_DIRS_AT_BOOTUP in 12.1, I am now mounting “/tmp” from swap in all 4 systems that I use.
To mount “/tmp”, I add the following line to “/etc/fstab”:
none /tmp tmpfs defaults 0 0
If I prefer to limit “/tmp” to 100M, then I can instead use:
none /tmp tmpfs size=100m 0 0
Making that change to “/etc/fstab” does not affect anything until the next boot. I did not want to manually mount “/tmp”, because that would interfere with programs, including the X-server, that are currently using files in “/tmp”.
After rebooting, it is useful to go back and delete the files left in “/tmp”. Those are no longer visible, as they are hidden under the mounted tmpfs file system. I could either ignore those old files (they were not actually taking a lot of space), or delete them with:
# mount --bind / /mnt # cd /mnt/tmp # ls -altr ### sanity check to be sure I am in the right place # rm -rf * .??* # ls -al ### check that everything is removed # cd / # umount /mnt
I chose to delete them.
There’s an alternative, easier to remember, way of clearing them. Reboot the system, and put a “1” on the kernel parameter line at the grub prompt. This boots into single user mode. When booted, give the root password. Then “umount /tmp”, and then delete the files in “/tmp”. Finally, use “shutdown -r now” for another reboot after this cleanup.
So what should the openSUSE developers do about the situation?
Fred Crozat has suggested that we look at “/bin/systemd-tmpfiles” to clean temporary files. That looks fine for an ongoing way of cleaning files as they become stale. But it isn’t obvious how to use it for a forced cleaning during boot.
Since mounting “/tmp” from swap (or tmpfs) seems to work pretty well, perhaps that’s the way to go. So here are my suggestions:
- Change the documentation for CLEAR_TMP_DIRS_AT_BOOTUP to indicate that it only applies when booting with sysvinit, and not with systemd. And indicate that its use is deprecated.
- Add support to Yast for setting up the mounting of “/tmp” from swap. There should be a Yast option with this on the size limit (if desired). Yast would only have to make the changes to “/etc/fstab” and advise the user that they will take effect on reboot.
- Once this is in Yast, consider adding it as an option in the installer.
I’ll probably make those suggestions at the bugzilla report, with a link to here. Pertinent comments are welcome, but don’t try to spam.