/tmp is not cleaned when on a separate partition

mountall log at startup with a separate /tmp

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.

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)

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.

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

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.

Same behaviour here. And same separate /tmp partition.

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).

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
    command-line.
  * 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

Will there be a fix for Ubuntu 9.10?

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.

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
TMPTIME=0
$ 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/
lost+found

Additional information (I can provide more on request) :

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

$ apt-cache policy mountall
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

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.

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?

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
        done
    fi

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