Bug 1226528

Summary: unwanted automatic umount when device does not exist for nondev fs
Product: [Fedora] Fedora Reporter: Eduard Vopicka <eduard.vopicka>
Component: systemdAssignee: systemd-maint
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 22CC: bugzilla-redhat, drbasic6, eduard.vopicka, hedayatv, johannbg, jonathan, jsynacek, kzak, lnykryn, msekleta, s, systemd-maint, zbyszek
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: systemd-219-19.fc22 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-03 13:26:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Eduard Vopicka 2015-05-30 10:33:23 UTC
Description of problem: mount -t ramfs behaves incorrectly. The biggest of the problems is that exit status is 0 with nothing actually mounted.


Version-Release number of selected component (if applicable): util-linux-2.26.2-1.fc22.i686

How reproducible: Always

Steps to Reproduce:

# As root, try the following
mkdir /var/tmp/y
mount -t ramfs /dev/nonexistent /var/tmp/y
echo $?
mount | grep /var/tmp/y
umount /var/tmp/y
rmdir /var/tmp/y



Actual results:
Nothing mounted.
No error message from mount
mount exit status is 0.

[root@lin ~]# mount -t ramfs /dev/nonexistent /var/tmp/y
[root@lin ~]# echo $?
0
[root@lin ~]# mount | grep /var/tmp/y
[root@lin ~]# umount /var/tmp/y
umount: /var/tmp/y: not mounted
[root@lin ~]# rmdir /var/tmp/y
[root@lin ~]# 
[root@lin ~]# 


Expected results:
Appropriate error message should be output and error exit status returned.

Additional info: Amazingly, if you use some existing path instead of /dev/nonexistent (e.g, something like /dev/sda1 or /var/tmp/y), the mount is actually performed. This should be fixed to behave consistently and output appropriate error message and exit status. mount -t ramfs /var/tmp/y /var/tmp/y works. And yes, I know tha specifying device with -t ramfs id no good practice, with mount -t ramfs ramfs /some/directory is probably the cleanest solution.

Comment 1 Karel Zak 2015-06-01 09:25:07 UTC
ramfs is nodev filesystem, so it's absolutely fine to use arbitrary text as the mount source.

# strace -e mount  mount -t ramfs /dev/littlecat /hello/kitty
mount("/dev/littlecat", "/hello/kitty", "ramfs", MS_MGC_VAL, NULL) = 0
+++ exited with 0 +++

... kernel returns success. The more important is what happen with system mount table; on another console try:

# findmnt --poll

... after mount, you will see:

ACTION     TARGET       SOURCE         FSTYPE OPTIONS
mount      /hello/kitty /dev/littlecat ramfs  rw,relatime
ACTION     TARGET       SOURCE         FSTYPE OPTIONS
umount     /hello/kitty /dev/littlecat ramfs  rw,relatime

... filesystem has been mounted, but then immediately umounted. Let's try strace systemd:

sendmsg(3, ... {"MESSAGE=Unmounted /hello/kitty.", 31},

and see /varlog/messages (or journal):

Jun  1 11:07:44 ws systemd: Unit hello-kitty.mount is bound to inactive unit dev-littlecat.device. Stopping, too.
Jun  1 11:07:44 ws systemd: Unmounting /hello/kitty...
Jun  1 11:07:44 ws systemd: Unmounted /hello/kitty.


The nice thing is when you use as the mount source something what does not start with "/dev" then systemd does not care:

# mount -t ramfs /this/littlecat /hello/kitty
# findmnt /hello/kitty
TARGET       SOURCE          FSTYPE OPTIONS
/hello/kitty /this/littlecat ramfs  rw,relatime


IMHO it's pretty strange that any change in /proc/self/mountinfo triggers umount -- systemd should be very very careful to interpret mount(2) source strings, it's very FS specific.

Comment 2 Eduard Vopicka 2015-06-01 18:31:27 UTC
Hello.

Thanks for your analysis. I did not try anything except for reporting the bug after I have realized that using "/dev/sda1" or better "ramfs" for the mount source makes things working again for me.

The bug manifested itself in very old (6+ years, based on file timestamp) shell script. I am 100% sure that this script worked well with Fedora 20 and many previous Fedora versions.

Just curious why files under /dev are handled differently than in another location, while I believe it is OK (yes, also a bit unusual) to have special device files almost in any directory, not just uder /dev.

Brgds,

Ed

Comment 3 Lennart Poettering 2015-06-17 23:00:58 UTC
This is fixed upstream.

Comment 4 Lennart Poettering 2015-06-17 23:08:16 UTC
*** Bug 1226191 has been marked as a duplicate of this bug. ***

Comment 5 Fedora Update System 2015-07-08 02:35:49 UTC
systemd-219-19.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/systemd-219-19.fc22

Comment 6 Fedora Update System 2015-07-10 19:18:04 UTC
Package systemd-219-19.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-219-19.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-11332/systemd-219-19.fc22
then log in and leave karma (feedback).

Comment 7 Eduard Vopicka 2015-07-11 05:39:20 UTC
Hello. systemd-219-19.fc22 not fix this bug.

[root@lin ~]# mount -t ramfs /dev/nonexistent /M
[root@lin ~]# rpm -q systemd
systemd-219-19.fc22.i686
[root@lin ~]# 

Jul 11 07:35:06 lin.local systemd[1]: Unit M.mount is bound to inactive unit dev-nonexistent.device. Stopping, too.
Jul 11 07:35:06 lin.local systemd[1]: Unmounting /M...
Jul 11 07:35:07 lin.local systemd[1]: Unmounted /M.

Comment 8 Fedora Update System 2015-07-14 15:31:51 UTC
systemd-219-19.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Eduard Vopicka 2015-07-15 15:57:51 UTC
Hello.

systemd-219-19.fc22.i686 **does*not*fix** this bug.

[root@lin ~]# mkdir /tmp/M
[root@lin ~]# mount -t ramfs /dev/nonexistent /tmp/M
[root@lin ~]# mount |grep /tmp/M
[root@lin ~]# rpm -q systemd
systemd-219-19.fc22.i686
[root@lin ~]# 

Jul 15 17:41:18 lin.local systemd[1]: Unmounted /tmp/M.
Jul 15 17:41:18 lin.local systemd[1]: Unmounting /tmp/M...
Jul 15 17:41:18 lin.local systemd[1]: Unit tmp-M.mount is bound to inactive unit dev-nonexistent.device. Stopping, too.

I have trouble to understand what happens with this bug. Looks to me that system critical path component to be released has not been tested for bug it is supposed to fix and which is always and easily reproducible.

Comment #7 here and negative karma is not enough to prevent this ticket to be closed with resolution ERRATA.

Brgds,

Ed

Comment 10 Basic Six 2015-08-28 15:07:06 UTC
Is this related to bug 1214069?

Similar log entries generated by systemd in both cases:
"Unit (...).mount is bound to inactive unit (...). Stopping, too."

Comment 11 Karel Zak 2015-11-05 12:26:55 UTC
I can confirm that the problem is not fixed (tested with systemd-219-25.fc22.x86_64).

Added a new issue to the upstream tracker: https://github.com/systemd/systemd/issues/1788

Comment 12 Zbigniew Jędrzejewski-Szmek 2015-11-27 18:45:38 UTC
I can reproduce this easily on F22, but not on F23 or rawhide (despite running mount in a loop in a few different configurations, and without the fix in https://github.com/systemd/systemd/pull/2017). A lot changed between F22 (systemd-219) and F23 (systemd-222). 628c89cc68ab96fce2de7ebba5933725d147aecc could be it, but there were other commits later on (fcd8b266edf0df2b85079fcf7b099cd4028740e6, 394763f63c1941cafd9d3bf81e8151a2206474a7, c0a7f8d3cb757cf750fc6788df0d215f6457c09d, we also switched to use mountinfo...).

Comment 13 Zbigniew Jędrzejewski-Szmek 2015-11-27 18:46:58 UTC
I don't think any significant backport is feasible. Maybe we should document the workarounds:
a) removing the line from fstab
b) not using /dev/... prefix

Comment 14 Eduard Vopicka 2015-11-27 19:48:13 UTC
Re: comment #13: Please take a look at bug 1214069 (as pointed here in comment #10). In that bug the problem manifests with btrfs mount, where you only hardly can omit /dev/ prefix.

Comment 15 Zbigniew Jędrzejewski-Szmek 2016-04-03 12:55:11 UTC
*** Bug 1214069 has been marked as a duplicate of this bug. ***

Comment 16 Zbigniew Jędrzejewski-Szmek 2016-04-03 13:26:35 UTC
The fix is not going to be backported to F22, it's too complicated.

If you can, use one of the workarounds listend in comment #13, otherwise upgrade to F23+. Sorry.

Comment 17 Brian 2016-06-28 16:09:28 UTC
FYI: This is still present under F23

systemd-222-14.fc23.x86_64

It only started showing up after I added the "noauto" option to the btrfs mount, but then removing it and systemd daemon-reload didn't seem to stop the unmounting.  Commenting it completely out of fstab and reloading systemd did.