Bug 663108

Summary:	API mounts ignore fstab options
Product:	[Fedora] Fedora	Reporter:	Garrett Holmstrom <gholms>
Component:	systemd	Assignee:	Lennart Poettering <lpoetter>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	kzak, lpoetter, metherid, mschmidt, notting, plautrba
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-02-09 13:41:19 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Garrett Holmstrom 2010-12-14 18:07:04 UTC

Description of problem:

The portion of systemd that handles API mounts initially mounts filesystems with hardcoded options, meaning they later have to be remounted by systemd-remount-api-vfs when the options given in fstab differ.  While there is no getting around remounting filesystems mounted in the initramfs, systemd has access to fstab and might as well consult it when determining how to mount whichever API filesystems that appear there.

This is related to, but not the cause of, a recent devel list thread [1].  The cause is a different bug where systemd-remount-api-vfs doesn't seem to work properly [2].

[1] http://lists.fedoraproject.org/pipermail/devel/2010-December/147080.html
[2] http://lists.fedoraproject.org/pipermail/devel/2010-December/147142.html


Version-Release number of selected component (if applicable):
systemd-15-1.fc15.x86_64

Comment 1 Lennart Poettering 2011-01-05 20:21:37 UTC

Hmm, weird, this works fine here.

If I invoke /lib/systemd/systemd-remount-api-vfs manually as root all settings from /etc/fstab are properly applied. I added and removed a "noexec" from the /dev/shm line and it always got properly applied to the mount options of /dev/shm by invoking /lib/systemd/systemd-remount-api-vfs.

Can anybody reproduce the issue with /lib/systemd/systemd-remount-api-vfs started manually? If you can, could you run "strace -f -e execve /lib/systemd/systemd-remount-api-vfs" to see whether /bin/mount is properly invoked by the tool for your mount point? If it is invoked, then the bug is presumably in mount, not in systemd.

Hmm, thinking about it here's my (educated) guess what really was going on: systemd does not clean up /etc/mtab, because we want this to be replaced by a symlink to /proc/mounts, a change which will happen shortly in the util-linux package but so far has not been made yet. So, because mtab wasn't cleaned up it still included (mutliple) /dev/shm entries from a previous boot. When systemd-remount-api-vfs invoked /bin/mount the latter found those entries and was confused and got tricked into not actually applying the mount options from /etc/fstab because it assumed they already were there. Or something like that.

Karel, can you comment whether this explanation makes any sense at all?

If it does then an update to util-linux which includes the symlink should fix this problem for good.

Comment 2 Lennart Poettering 2011-01-05 20:23:04 UTC

(And of course, if this is indeed the right explanation then replacing /etc/mtab by a symlink to /proc/self/mounts should fix it.)

Comment 3 Lennart Poettering 2011-02-09 13:41:19 UTC

OK, closing due to lack of response. I presume anyway that this is fixed by mount installing /etc/mtab as symlink now. Feel free to reopen if this problem continues to exist.