/tmp is not cleaned when on a separate partition

Bug #478392 reported by Fabien SK
This bug affects 16 people
Affects Status Importance Assigned to Milestone
mountall (Ubuntu)

Bug Description

Binary package hint: mountall

Version: Kubuntu 9.10
Arch: amd64
Package version: 1.0

When /tmp is on the same partition than root, mountall cleans it at startup. The end of the "mountall --debug" (tip: I redirected it to "/dev/mountall.log" because /dev is writable at this time of the startup) looks like that:

run_mount: /tmp: hook
mounted: /tmp
tmp_hook: cleaning up /tmp
local finished

When /tmp is in a separte ext2 or ext4 partition, it's not cleaned anymore. "tmp_hook" is not called. Please find attached the full log.

Revision history for this message
Fabien SK (fabsk) wrote :

mountall log at startup with a separate /tmp

Revision history for this message
vyncere (vyncere) wrote :

Hello everyone,

I can confirm the problem.

Here is my duplicate bug report : https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/478520

Thank you very much in advance.

Changed in mountall (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

This is because the separate /tmp in fstab overrites the internal hook function pointer (by design)

The right fix for this is going to be do take /tmp cleaning out of mountall and into an Upstart job invoked when the filesystem is mounted (leaving the dummy /tmp mount in so it's still triggered on /tmp-less boots)

Revision history for this message
Hadmut Danisch (hadmut) wrote :

But if you put the cleaning into a separate upstart job run after filesystem is mounted, how would you avoid that it removes files freshly created by other processes?

the filesystem must be clean before the signal local-filesystems is emitted.

Revision history for this message
Fabien SK (fabsk) wrote :

You could only remove files that are older than let's say 1 minutes. But I'm afraid that something like that happens:
- "local-filesystems" is emitted
- some program X checks that some file/directory already exists in /tmp. It does, so it doesn't need to create it
- the upstart job is launched and cleans /tmp
- the program X fails to run properly because it assumed that the file/directory existed

Revision history for this message
H.-R. Oberhage (oberhage) wrote :

Comming back to the 'merged' bug #470797: Can't you just 'mimic' the Sys-V-init behaviour in "upstart". That seemed to work satisfactorily. Package 'initscripts' installed a shell-script mountall-bootclean.sh which started some helper (also a shell-script, iirc) that did the actual job. It's all still there in 'jaunty'. There surely is a way to just incorporate that (the helper shell-script) into "upstart", at least as a starting point.

Revision history for this message
Julien Aubin (gojulgarbmail) wrote :

Same behaviour here. And same separate /tmp partition.

Revision history for this message
Fabien SK (fabsk) wrote :

Please find attached my "/etc/init/cleantmp.conf"

Note that the script present in the previous version of Ubuntu is more complex, so I guess that it can handle more cases. For instance, I don't know what would happen if some other process writes some file in /tmp before my script is executed. And it could also be vunerable to some attacks (links or stuff like that).

Revision history for this message
Fabien SK (fabsk) wrote :
Changed in mountall (Ubuntu):
status: Triaged → Fix Committed
assignee: nobody → Scott James Remnant (scott)
Changed in mountall (Ubuntu):
milestone: none → lucid-alpha-2
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mountall - 2.0

mountall (2.0) lucid; urgency=low

  [ Scott James Remnant ]
  * "mount" event changed to "mounting", to make it clear it happens
    before the filesystem is mounted. Added "mounted" event which
    happens afterwards.
  * Dropped the internal hooks, these are now better handled by Upstart
    jobs on the "mounted" event.
  * Dropped the call to restorecon for tmpfs filesystems, this can also be
    handled by an Upstart job supplied by SELinux now.
    - mounted-dev.conf replaces /dev hook, uses MAKEDEV to make devices.
    - mounted-varrun.conf replaces /var/run hook
    - mounted-tmp.conf replaces /tmp hook.
      + Hook will be run for any /tmp mountpoint. LP: #478392.
      + Switching back to using "find" fixes $TMPTIME to be in days again,
        rathern than hours. LP: #482602
  * Try and make mountpoints, though we only care about failure if the
    mountpoint is marked "optional" since otherwise the filesystem might
    make the mountpoint or something.
  * Rather than hiding the built-in mountpoints inside the code, put them
    in a new /lib/init/fstab file; that way users can copy the lines into
    /etc/fstab if they wish to override them in some interesting way.
  * Now supports multiple filesystem types listed in fstab, the whole
    comma-separated list is passed to mount and then /proc/self/mountinfo
    is reparsed to find out what mount actually did.
    * /dev will be mounted as a devtmpfs filesystem if supported by the
      kernel (which then does not need to run the /dev hook script).
  * Filesystem checks may be forced by adding force-fsck to the kernel
  * Exit gracefully with an error on failed system calls, don't infinite
    loop over them. LP: #469985.
  * Use plymouth for all user communication, replacing existing usplash and
    console code;
    * When plymouth is running, rather than exiting on failures, prompt the
      user as to whether to fix the problem (if possible), ignore the problem,
      ignore the mountpoint or drop to a maintenance shell. LP: #489474.
    * If plymouth is not running for whatever reason, the fallback action
      is always to start the recovery shell.
  * Adjust the set of filesystems that we wait for by default: LP: #484234.
    * Wait for all local filesystems, except those marked with the
      "nobootwait" option.
    * Wait for remote filesystems mounted as, or under, /usr or /var, and
      those marked with the "bootwait" option.
  * Always try network mount points, since we allow them to fail silently;
    SIGUSR1 now simply retries them once more. LP: #470776.
  * Don't retry devices repeatedly. LP: #480564.
  * Added manual pages for the events emitted by this tool.

  [ Johan Kiviniemi ]
  * Start all fsck instances in parallel, but set their priorities so that
    thrashing is avoided. LP: #491389.
 -- Scott James Remnant <email address hidden> Mon, 21 Dec 2009 23:09:23 +0000

Changed in mountall (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
TheGeneral (torge) wrote :

Will there be a fix for Ubuntu 9.10?

Revision history for this message
Paul Crawford (psc-sat) wrote :

I also want to know if this can be applied to 9.10?

I have an automatic back-up script that depends on /tmp being cleared at booting to cope with the machine being switched off mid-backup, so it is more important to me than just avoiding the build up of general detritus.

Simon Déziel (sdeziel)
Changed in mountall (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Simon Déziel (sdeziel) wrote :

I am reopening this bug as I am affected on my two Lucid systems. Here are the steps to reproduce :

$ grep TMPTIME /etc/default/rcS
$ mount | grep "/tmp"
/dev/mapper/stripe-tmp on /tmp type ext4 (rw,nosuid,nodev,noatime,commit=600,data=writeback,barrier=0)
$ touch /tmp/to-delete
$ ls /tmp/
lost+found to-delete
$ sudo reboot
$ ls /tmp/
lost+found to-delete

I tried "touching" a file in the directory /tmp on my root partition and neither the /tmp included in the root partition or the one on the separate partition is cleaned on reboot. The /tmp directory is cleaned when I run this :

$ sudo service mounted-tmp start
mounted-tmp stop/waiting
$ ls /tmp/

Additional information (I can provide more on request) :

$ lsb_release -rd
Description: Ubuntu 10.04.1 LTS
Release: 10.04

$ apt-cache policy mountall
  Installed: 2.15.2
  Candidate: 2.15.2
  Version table:
 *** 2.15.2 0
        500 http://ca.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages
        500 http://security.ubuntu.com/ubuntu/ lucid-security/main Packages
        100 /var/lib/dpkg/status
     2.14 0
        500 http://ca.archive.ubuntu.com/ubuntu/ lucid/main Packages

Thank you

Revision history for this message
Gregor Giesen (grgi) wrote :

This bug is also affecting maverick. I'm a bit bewildered how this bug did survive several releases.

On my lucid system before, I had /tmp on an extra xfs partition and changing the fs to ext4 did help.
But now with maverick I tried the btrfs on /tmp and no cleaning, but changing to ext4 does not remedy.

Changed in mountall (Ubuntu):
assignee: Scott James Remnant (scott) → nobody
Revision history for this message
Jan-Marek Glogowski (jmglogow) wrote :

I'm seeing the same problem on my Lucid server. Guessing from my "mountall --debug" log the problem seems to be, that /usr is also on a seperate partition and mounted-tmp.conf uses find to clean /tmp, which is on /usr but mounts /tmp before /usr.

I tried to use "start on (mounted MOUNTPOINT=/tmp and mounted MOUNTPOINT=/usr) but this deadlocks the boot process.

Any idea how to prevent the deadlock?

Revision history for this message
Bastien Durel (bastien-durel) wrote :

If find is used in system scripts, it must lives in /bin, IMHO.

or you may add something to wait in the script like this :
    if [ ! -x /usr/bin/find ] ; then
        for i in `seq 10` ; do
            if [ -x /usr/bin/find ] ; then break ; fi
            sleep 1

(but I don't succeed to test that, I cannot figure why)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.