Hello Christian,
On Sun, Jul 24, 2011 at 11:12:41PM +0200, Christian Kastner wrote:
> On 07/24/2011 09:38 PM, Helge Kreutzmann wrote:
> > On Sun, Jul 24, 2011 at 08:42:04PM +0200, Christian Kastner wrote:
> >> cron decides on whether to run @reboot jobs by checking if the file
> >> /var/run/crond.reboot exists. If it exists, cron skips @reboot jobs; if
> > 
> > root@sneo:~# ls -l /var/run/crond.reboot
> > ---------- 1 root root 0  9. Jul 13:36 /var/run/crond.reboot
> > 
> > Clearly looks like it has not been removed.
> > 
> >> In your case, the /var/run/crond.reboot seems to be preserved across
> >> reboots, which I cannot reproduce. Could you post the output of
> >> `mount | grep run` here?
> > 
> > tmpfs on /var/run/lock type tmpfs
> > (rw,noexec,nosuid,nodev,size=5242880,mode=1777,size=5242880,mode=1777)
> > tmpfs on /var/run/shm type tmpfs
> > (rw,nosuid,nodev,size=20%,mode=1777,size=20%,mode=1777)
> > tmpfs on /var/run type tmpfs
> > (rw,noexec,nosuid,relatime,size=818528k,mode=755)
> > 
> > Shouldn't a tmpfs be empty after a reboot?
> 
> Definitely yes.
> 
> /var/run/crond.reboot still being there would indicate that there's
> another FS in play, but I wouldn't really know why this is happening.
> One possibility would be that something went wrong during the recent
> /var/run -> /run transition (I see the above mounts under /run)

/run is a symlink to /var/run on that machine.

> Could you look into /etc/fstab (and maybe /etc/default/tmpfs) and see if
> you can spot something fishy?

/etc/fstab:
/dev/mapper/system_vg-var_vg /var            ext3 nodev,nosuid,data=ordered 0   
    2
/dev/mapper/system_vg-aptcache_lv /var/cache/apt-cacher-ng
ext3    nodev,nosuid,noexec,data=ordered    0       2

Those tmpfs file systems are not mentioned.

I did not touch /etc/default/tmpfs, the non comment options are:
TMPFS_SIZE=20%
RUN_SIZE=10%
LOCK_SIZE=5242880 # 5MiB
SHM_SIZE=
TMP_SIZE=
RW_SIZE=5242880 # 5 MiB

However, I see the following error message:
syslog.1:Jul 24 18:31:11 sneo kernel: tmpfs: Bad mount option data

So somehow the tmpfs-entries inherit the mount options from /var?

I removed the "data=ordered" from /var and together with the following
changes, the "Bad mount option" error message is gone.

Next I tried to get tmpfs mounted on /var/run

I disabled the other two tmpfs entries in /etc/default/rcS, i.e.
/run/lock and /runshm.

I added /var/run explicitly into /etc/fstab
tmpfs   /var/run        tmpfs   nodev,nosuid,size=5242880,mode=755
0      0

Now, after a reboot, tmpfs is supposedly mounted (i.e. mount|grep
tmpfs). However, the files in /var/run look like before. When I umount
/var/run, I get an error message that the file system is not mounted.
Now, in mount|grep tmpfs /var/run is no longer listed. When I mount
/var/run explicitly afterwards, /var/run is empty as expected (and
tmpfs mounted).

I'm clearly running out of ideas how to get /var/run mounted as tmpfs.
Actually, I probably don't understand which script mounts what and
when; ideally, /var/run would simply be zeroed at reboot...

If you have any ideas, they are gladly appreciated.

Greetings

          Helge
-- 
      Dr. Helge Kreutzmann                     deb...@helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

Attachment: signature.asc
Description: Digital signature

Reply via email to