Bug 783884 - Mount options in /etc/fstab for /dev/shm are not honored.
Summary: Mount options in /etc/fstab for /dev/shm are not honored.
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts
Version: 6.2
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: ---
Assignee: Lukáš Nykrýn
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1075802 1159926
TreeView+ depends on / blocked
 
Reported: 2012-01-23 05:20 UTC by Ricky Zhou
Modified: 2018-12-04 14:31 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-04 16:56:22 UTC


Attachments (Terms of Use)
Proposed patch (617 bytes, patch)
2012-03-05 13:00 UTC, Harald Hoyer
no flags Details | Diff

Description Ricky Zhou 2012-01-23 05:20:49 UTC
On fedorapeople.org, we have the following in /etc/fstab:

tmpfs   /dev/shm    tmpfs   noexec,nosuid,nodev 0   0

However, on a reboot, /proc/mounts shows that /dev/shm is not mounted with these options.  The cause seems to be that /dev/shm is initially mounted in the initramfs, and then line 490 of /etc/rc.d/rc.sysinit performs a "fake" mount of /dev/shm before mounting the rest of the filesystems.  This causes /etc/mtab and the mount command to show that /dev/shm has the proper mount options when that isn't actually the case.

Comment 2 Bill Nottingham 2012-01-23 17:34:36 UTC
-> dracut.

Comment 3 RHEL Product and Program Management 2012-01-24 13:29:19 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Comment 5 Harald Hoyer 2012-03-01 17:20:51 UTC
rc.sysinit should do:

mount /dev -oremount
mount /dev/shm -oremount
mount /dev/pts -oremount
mount /proc -oremount
mount /sys -oremount

or fix mount and do:

mount -a -oremount

after /etc/mtab is rw

Comment 7 Bill Nottingham 2012-03-01 19:16:16 UTC
Why should initscripts do that instead of dracut using the specified options to begin with? (Among other reasons, it is racy...)

Comment 8 Harald Hoyer 2012-03-01 19:19:03 UTC
because these are mounted before dracut can even access /etc/fstab...

Btw, systemd does "mount -a -oremount" on boot time.

Comment 9 Harald Hoyer 2012-03-01 19:20:34 UTC
(In reply to comment #7)
> Why should initscripts do that instead of dracut using the specified options to
> begin with? (Among other reasons, it is racy...)

what is racy?

Comment 10 Bill Nottingham 2012-03-01 19:23:04 UTC
(In reply to comment #8)
> because these are mounted before dracut can even access /etc/fstab...

When creating the initramfs, it can use the options from the existing fstab. (Yes, it requires remaking the initramfs if you change the options.)

(In reply to comment #9)
> what is racy?

Requiring remount in initscripts means there's always a window where the fs has the 'wrong' options. Admittedly, in this case it's unlikely to ever amount to much.

Comment 11 Harald Hoyer 2012-03-05 13:00:07 UTC
Created attachment 567602 [details]
Proposed patch

Comment 12 Bill Nottingham 2012-03-05 19:58:53 UTC
I could see doing this... on the other hand, if you're trying to specify alternate options for /proc and /sys, you're trying to break your system. Also, the patch assumes all those filesystems are mounted, which they may not be.

Comment 13 David Mansfield 2012-04-05 21:05:01 UTC
I'd like to add that the "size=xxxx" option for /dev/shm is ignored by the current system, and a hacky:

mount -o remount /dev/shm

in rc.local is required to fix.  I have regenerated the initramfs after changing fstab to prove to myself it's ignored.

In comment#10, Bill recommended reading fstab, but I think it's counter-intuitive that a change in /etc/fstab would require regenerating the initramfs to take effect, especially if a one-line fix in rc.sysinit will do the trick (referring only to my specific /dev/shm size problem here).

Comment 15 RHEL Product and Program Management 2012-07-10 08:35:59 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 16 RHEL Product and Program Management 2012-07-10 23:25:54 UTC
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 18 Václav Pavlín 2012-08-08 13:57:17 UTC
We went through possibilities of how to cover notes from Bill's comment. The window mentioned in comment #10 should do no harm, because the same behaviour (remount everything in fstab) can be found in systemd (systemd-remount-fs.service) and Upstart. With this in mind, patch attached to this bug should be ok. We would just hide error messages from /dev, /dev/shm and /dev/pts remounts - if these are not mounted, error message is emitted, but nothing else happens.

Comment 20 Burhan Ali 2013-02-07 10:11:50 UTC
(In reply to comment #13)
> I'd like to add that the "size=xxxx" option for /dev/shm is ignored by the
> current system, and a hacky:
> 
> mount -o remount /dev/shm
> 
> in rc.local is required to fix.

rc.local is run last. What would be a suitable workaround if the remount is needed earlier? I have an Oracle system which needs /dev/shm to be a certain size. The fstab values being ignored means that Oracle does not start up and in turn all the things that depend on Oracle fall over.

Comment 21 Lukáš Nykrýn 2013-02-07 13:24:54 UTC
Easiest but probably not so nice solution is to create initscript with low start number which will do the job.

Comment 22 David Zambonini 2013-02-20 13:20:40 UTC
mount -o remount /dev/shm 

does not honour the mode= mount option in tmpfs.

Comment 23 Harald Hoyer 2013-03-18 10:48:25 UTC
(In reply to comment #22)
> mount -o remount /dev/shm 
> 
> does not honour the mode= mount option in tmpfs.

probably mount needs a patch, then

Comment 24 Lukáš Nykrýn 2013-04-02 16:25:25 UTC
(In reply to comment #22)
> mount -o remount /dev/shm 
> 
> does not honour the mode= mount option in tmpfs.

Can you post some reproducer to this? Because on my rhel6

[root@rhel6 ~]# grep shm /etc/fstab 
tmpfs                   /dev/shm                tmpfs   defaults        0 0
[root@rhel6 ~]# mount | grep shm
tmpfs on /dev/shm type tmpfs (rw)
[root@rhel6 ~]# vim /etc/fstab 
[root@rhel6 ~]# grep shm /etc/fstab 
tmpfs                   /dev/shm                tmpfs   mode=777        0 0
[root@rhel6 ~]# mount -o remount /dev/shm
[root@rhel6 ~]# mount | grep shm
tmpfs on /dev/shm type tmpfs (rw,mode=777)

Comment 25 David Zambonini 2013-05-24 21:05:34 UTC
Certainly, examine the filesystem instead of relying on mtab (note mode=777 is the default and therefore is not a good test case):

$ grep shm /etc/fstab
tmpfs                   /dev/shm                tmpfs   defaults        0 0
$ ls -ld /dev/shm
drwxrwxrwt 2 root root 40 May 24 21:59 /dev/shm
$ vi /etc/fstab
tmpfs                   /dev/shm                tmpfs   mode=770        0 0
$ mount -oremount /dev/shm
$ ls -ld /dev/shm
drwxrwxrwt 2 root root 40 May 24 21:59 /dev/shm
$ mount | grep shm
tmpfs on /dev/shm type tmpfs (rw,mode=770)

Comment 30 Lukáš Nykrýn 2015-02-27 11:39:03 UTC
We are remounting /dev/shm since rhel-6.4 a it seems to work on my machine, maybe if there are some options which are not applied than this could be a bug in mount.

Comment 31 Karel Zak 2015-02-27 14:35:29 UTC
Some notes:

- always check /proc/mounts or /proc/self/mountinfo on old systems with classic mtab. Never rely on "mount | grep"...

- mount(8) parses only mount flags (e.g. nosuid), but the rest is send to kernel as string and all depends on kernel.

- it's naive to assume that you can change arbitrary mount option by remount 
  - kernel (VFS) supports remount for basic mount flags like nosuid,noexec,...
  - the another options depends on FS driver and it's pretty common that you cannot change many FS mount options on the fly

 (for example kernel tmpfs (mm/shmem.c: shmem_remount_fs()) cares about size=, mpol=.. but no about mode=)

- it's pretty simple to debug mount(8), just use strace to see mount(2) syscall:

# strace -e mount mount -o remount,mode=777 /dev/shm

mount("tmpfs", "/dev/shm", 0x7f3af256c250, MS_MGC_VAL|MS_NOSUID|MS_NODEV|MS_REMOUNT, "seclabel,mode=777") = 0
+++ exited with 0 +++

Comment 34 David Zambonini 2015-03-04 12:49:23 UTC
Bug as described still exists, not all /etc/fstab mount options are honoured after boot, and those that are are applied in a racy manner and cannot be relied on to be present. This as I understand it is an architectural problem with dracut, which expects remount to work for all options, rather than intended behaviour.

At the very least mark this WONTFIX, or document that you have deprecated /etc/fstab?

Comment 35 Karel Zak 2015-03-04 15:08:53 UTC
(In reply to David Zambonini from comment #34)
> Bug as described still exists, not all /etc/fstab mount options are honoured
> after boot, and those that are are applied in a racy manner and cannot be
> relied on to be present. This as I understand it is an architectural problem
> with dracut, which expects remount to work for all options, rather than
> intended behaviour.

OK.

> At the very least mark this WONTFIX, or document that you have deprecated
> /etc/fstab?

fstab is not deprecated... re-assigning back to initscripts, from mount(8) point of view there is no bug.

Comment 36 Lukáš Nykrýn 2015-03-04 16:56:22 UTC
> - it's naive to assume that you can change arbitrary mount option by remount 
>   - kernel (VFS) supports remount for basic mount flags like
> nosuid,noexec,...
>   - the another options depends on FS driver and it's pretty common that you
> cannot change many FS mount options on the fly
> 
>  (for example kernel tmpfs (mm/shmem.c: shmem_remount_fs()) cares about
> size=, mpol=.. but no about mode=)
> 

According to this we can't do anything better in initscripts. So closing as can't fix.


Note You need to log in before you can comment on or make changes to this bug.