[Pkg-sysvinit-devel] Bug#665995: fstab actually not overriding RAMTMP ?

[Roger Leigh]

On Sun, Apr 15, 2012 at 01:32:52PM +0100, J M Cerqueira Esteves wrote:
> According to Roger Leigh <rleigh at codelibre.net>
> 
> > The RAMTMP setting only has an effect when there are no fstab
> > entries--the fstab entry (if any) will override the RAMTMP setting.
> 
> but it seems /etc/rcS.d/S01mountkernfs.sh actually only lets fstab
> override RAMTMP when it has a tmpfs entry for /tmp:
> 
> 1) When root is read-only, RAMTMP is forced to "yes" when there's an
> fstab entry, but existence of a fstab entry doesn't force RAMTMP to be "no":
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> # If root is read only, default to mounting a tmpfs on /tmp,
> # unless one is due to be mounted from fstab.
> if [ rw != "$rootmode" ]; then
>    # If there's an entry in fstab for /tmp (any
>    # filesystem type, not just tmpfs), then we don't need
>    # a tmpfs on /tmp by default.
>    if read_fstab_entry /tmp ; then
>       :
>    else
>       RAMTMP="yes"
>    fi
> fi
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 2) After the above, if RAMTMP is "yes" it is only overriden by a fstab
> entry with /tmp as tmpfs:
> 
> # Mount /tmp as tmpfs if enabled.
> if [ yes = "$RAMTMP" ] || read_fstab_entry /tmp tmpfs; then
>   domount "$MNTMODE" tmpfs shmfs /tmp tmpfs "-onodev,nosuid$TMP_OPT"
> 
> 
> In my recently installed Wheezy machine, the end effect is that I have
> two /tmp mounts, both with the same size (wondering why the size is the
> same... or maybe I failed to understand something)

No, you are correct.  There's a deficiency in the logic here.  To
correct it, I think we should probably use the following logic:

RAMTMP  FSTAB      MOUNT?
yes     no         yes
no      no         no
yes     tmpfs      yes
no      tmpfs      yes (*)
yes     non-tmpfs  no  (*)
no      non-tmpfs  no

The (*) indicates cases where we currently do the opposite, which
need correcting.  MOUNT is whether or not we should mount a tmpfs
based on the RAMTMP setting and/or any fstab entry which may be
present, including both tmpfs and other mounts.  We should probably
also deal with shmfs and ramfs mounts for completeness.

I'm wondering if we should probably also have the same logic for all
the other tmpfs mounts as well.  I'm currently thinking no, because
they are intended to be tmpfses 100% of the time, but there are cases
where this does not hold e.g. GNU/Hurd (no tmpfs).  But since Hurd
is currently not using initscripts, I'm not sure if it's worth
doing just to work around a deficiency in hurd.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800