Bug 712093 - bind mount entries in fstab result in duplicate mounts
Summary: bind mount entries in fstab result in duplicate mounts
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-09 13:50 UTC by Tom Horsley
Modified: 2011-06-30 12:21 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-06-30 12:18:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/etc/fstab from affected system. (1.95 KB, text/plain)
2011-06-30 12:09 UTC, Frank Crawford
no flags Details

Description Tom Horsley 2011-06-09 13:50:12 UTC
Description of problem:
Put a line like this in /etc/fstab:

/caliban/web-content/html	/var/www/html	none	rw,bind	0	0

See this after the system boots:

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda6             416G  124G  271G  32% /caliban
/dev/sda6             416G  124G  271G  32% /var/www/html
/dev/sda6             416G  124G  271G  32% /var/www/html

Note that there is the duplicate due to df no longer knowing about bind mounts, but there is also yet another duplicate because the /var/www/html mount was apparently done twice. This 2nd duplicate is what this bug is about.

If I do not put the bind mount in /etc/fstab, but simply run the mount command manually after the system is up, then only one instance of /var/www/html shows up in the df output (or /proc/mounts, etc).

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


How reproducible:
every time

Steps to Reproduce:
1.see above
2.
3.
  
Actual results:
duplicate mounts of bind mounts in fstab

Expected results:
Only one mount of the bind mount

Additional info:
I want to emphasize that this is not a duplicate of bug 709351. That bug is about the df command displaying things it should not. This bug is about a bind mount happening twice during boot. It is also not a duplicate of bug 701176, which was apparently closed because sandbox was changed. This has nothing to do with sandbox.

Comment 1 Lennart Poettering 2011-06-14 19:23:05 UTC
Do you have sandbox installed? 

Is /etc/mtab a symlink for you?

Can you paste the contents of /proc/mounts please? Is the entry duplicate there, too?

Comment 2 Tom Horsley 2011-06-14 21:07:48 UTC
> Do you have sandbox installed? 

It is installed, but not enabled as a service:

zooty> chkconfig --list sandbox
sandbox         0:off   1:off   2:off   3:off   4:off   5:off   6:off

> Is /etc/mtab a symlink for you?

Apparently yes (I didn't do that - this is a fresh install of f15 from
the DVD iso, so something else set this up):

zooty> ls -l /etc/mtab
lrwxrwxrwx. 1 root root 12 May 24 17:30 /etc/mtab -> /proc/mounts

> Can you paste the contents of /proc/mounts please? Is the entry duplicate
> there, too?

zooty> cat /proc/mounts
rootfs / rootfs rw 0 0
/proc /proc proc rw,relatime 0 0
/sys /sys sysfs rw,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=4088408k,nr_inodes=1022102,mode=755 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
tmpfs /run tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0
/dev/sda9 / ext3 rw,relatime,errors=continue,user_xattr,acl,barrier=0,data=ordered 0 0
tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/ns cgroup rw,nosuid,nodev,noexec,relatime,ns 0 0
cgroup /sys/fs/cgroup/cpu cgroup rw,nosuid,nodev,noexec,relatime,cpu 0 0
cgroup /sys/fs/cgroup/cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
systemd-1 /dev/hugepages autofs rw,relatime,fd=35,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /sys/kernel/debug autofs rw,relatime,fd=36,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /dev/mqueue autofs rw,relatime,fd=37,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /sys/kernel/security autofs rw,relatime,fd=38,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=39,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
tmpfs /media tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
/dev/sdb2 /zooty ext3 rw,relatime,errors=continue,barrier=0,data=ordered 0 0
/dev/sdb2 /var/www/html ext3 rw,relatime,errors=continue,barrier=0,data=ordered 0 0
/dev/sdb2 /home ext3 rw,relatime,errors=continue,barrier=0,data=ordered 0 0
/dev/sda6 /r+b/i386/f14/root ext3 rw,relatime,errors=continue,user_xattr,acl,barrier=0,data=ordered 0 0
/dev/sda3 /r+b/i386/f15/root ext3 rw,relatime,errors=continue,user_xattr,acl,barrier=0,data=ordered 0 0
/dev/sda7 /r+b/amd64/f13/root ext3 rw,relatime,errors=continue,user_xattr,acl,barrier=0,data=ordered 0 0
/dev/sda5 /r+b/amd64/f14/root ext3 rw,relatime,errors=continue,user_xattr,acl,barrier=0,data=ordered 0 0
/dev/sda2 /spare ext3 rw,relatime,errors=continue,user_xattr,acl,barrier=0,data=ordered 0 0
/dev/sda1 /mainboot ext3 rw,relatime,errors=continue,user_xattr,acl,barrier=0,data=ordered 0 0
/dev/sda8 /r+b/i386/f13/root ext3 rw,relatime,errors=continue,user_xattr,acl,barrier=0,data=ordered 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
/dev/sdb2 /var/www/html ext3 rw,relatime,errors=continue,barrier=0,data=ordered 0 0
/dev/sdb2 /home ext3 rw,relatime,errors=continue,barrier=0,data=ordered 0 0
nfsd /proc/fs/nfsd nfsd rw,relatime 0 0
/dev/sdc5 /backup ext3 rw,noatime,errors=continue,barrier=0,data=ordered 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
securityfs /sys/kernel/security securityfs rw,relatime 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0

/home and /var/www/html are both bind mounts on my system and both
show up twice in /proc/mounts.

Comment 3 Cristian Ciupitu 2011-06-15 15:14:37 UTC
I'm having the same problem with these lines from fstab:

/home/ciupicri/mystore		/srv/mystore		none	bind	0	0
/home/ciupicri/mystore-media	/srv/mystore-media	none	bind	0	0
/home/ciupicri/mystore-static	/srv/mystore-static	none	bind	0	0

[root@shop ~]# chkconfig --list | fgrep sandbox
sandbox        	0:off	1:off	2:off	3:off	4:off	5:off	6:off

[root@shop ~]# mount |fgrep mystore
/dev/vda2 on /srv/mystore type ext4 (ro,relatime,seclabel,barrier=1,data=ordered)
/dev/vda2 on /srv/mystore-media type ext4 (ro,relatime,seclabel,barrier=1,data=ordered)
/dev/vda2 on /srv/mystore-static type ext4 (ro,relatime,seclabel,barrier=1,data=ordered)
/dev/vda2 on /srv/mystore type ext4 (rw,relatime,seclabel,barrier=1,data=ordered)
/dev/vda2 on /srv/mystore-media type ext4 (rw,relatime,seclabel,barrier=1,data=ordered)
/dev/vda2 on /srv/mystore-static type ext4 (rw,relatime,seclabel,barrier=1,data=ordered)

[root@shop ~]# ls -l /etc/mtab 
lrwxrwxrwx. 1 root root 12 Jun 14 15:59 /etc/mtab -> /proc/mounts

Comment 4 Nils Philippsen 2011-06-24 06:58:18 UTC
I see the same issue on one of my machines. Taking one mount point as example, /data is bind-mounted to /export/data:

nils@wombat:~> grep /data /etc/fstab
UUID=07a5b413-3882-4d0b-881d-e78876b5b283 /data                   ext4    defaults        1 2
/data                   /export/data            none    bind    0 0
nils@wombat:~> mount | grep /data
/dev/mapper/vg_wombat-lv_data on /data type ext4 (rw,relatime,seclabel,barrier=1,data=ordered)
/dev/mapper/vg_wombat-lv_data on /export/data type ext4 (rw,relatime,seclabel,barrier=1,data=ordered)
nils@wombat:~> grep /data /proc/mounts
/dev/mapper/vg_wombat-lv_data /data ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0
/dev/mapper/vg_wombat-lv_data /export/data ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0
nils@wombat:~> 

Occasionally, the bind mount operation is done before the actual mount, leading to /etc/data being bound to the root FS (the empty mount point) and /data later on not being mounted. Is this issue known or do you want a separate bugreport?

Comment 5 Tom Horsley 2011-06-24 12:55:41 UTC
I'm not the one to ask about separate bug reports, but I notice that
with the latest updates, I didn't see the duplicate bind mount:

systemd-units-26-4.fc15.x86_64
systemd-26-4.fc15.x86_64
systemd-sysv-26-4.fc15.x86_64
kernel-2.6.38.8-32.fc15.x86_64

Of course if it is timing related, perhaps I was just lucky, but I did get
systemd updates at the same time the problem disappeared, so I hope that's
a good sign.

Comment 6 Frank Crawford 2011-06-25 09:26:24 UTC
(In reply to comment #5)
> I'm not the one to ask about separate bug reports, but I notice that
> with the latest updates, I didn't see the duplicate bind mount:
> 
> systemd-units-26-4.fc15.x86_64
> systemd-26-4.fc15.x86_64
> systemd-sysv-26-4.fc15.x86_64
> kernel-2.6.38.8-32.fc15.x86_64
> 
> Of course if it is timing related, perhaps I was just lucky, but I did get
> systemd updates at the same time the problem disappeared, so I hope that's
> a good sign.

I think it may be a timing issue for you, since I have the same updates and I'm still getting duplicates for bind mounts.

Comment 7 Michal Schmidt 2011-06-29 23:02:12 UTC
(In reply to comment #5)
> Of course if it is timing related, perhaps I was just lucky, but I did get
> systemd updates at the same time the problem disappeared, so I hope that's
> a good sign.

There was an update of util-linux. It may have helped.


Cristian and Nils are affected by bug 716483.

Frank, could you attach your /etc/fstab?

Comment 8 Frank Crawford 2011-06-30 12:09:53 UTC
Created attachment 510647 [details]
/etc/fstab from affected system.

Attached is /etc/fstab from the affected system.

Comment 9 Michal Schmidt 2011-06-30 12:18:55 UTC
Frank,
you are also affected by bug 716483. Your fstab has the same pattern.

I'm closing this bug as WORKSFORME because the problem disappeared for the original reporter and the other reporters are seeing bug 716483 instead.

Comment 10 Frank Crawford 2011-06-30 12:21:44 UTC
Yep, I just read that report and I agree it looks like the same problem.

Thanks.


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