Description of problem: System takes an extremely long time to boot when _netdev is listed in mntops in fstab. I'm mounting GlusterFS (ver 3.4.2) volumes in my fstab, and upon upgrading to Fedora 20, my system began to take extremely long time (15 minutes +) to boot. This wasn't the case in Fedora 18. I upgraded to Fedora 20 via fedup from Fedora 18 (with an intermediate upgrade to Fedora 19). After the system comes up, looking in the system logs I see this: ... [ 3.798568] systemd[1]: Successfully loaded SELinux policy in 289.975ms. [ 3.961543] systemd[1]: Relabelled /dev and /run in 33.512ms. [ 65.009329] systemd[1]: Found dependency on network.target/start [ 124.981970] systemd[1]: Found dependency on network.service/start [ 184.954598] systemd[1]: Found dependency on basic.target/start [ 244.927222] systemd[1]: Breaking ordering cycle by deleting job sockets.targe t/start [ 304.899852] systemd[1]: Job sockets.target/start deleted to break ordering cy cle starting with basic.target/start [ 364.872499] systemd[1]: Found ordering cycle on basic.target/start [ 424.845126] systemd[1]: Found dependency on sysinit.target/start [ 484.817753] systemd[1]: Found dependency on local-fs.target/start [ 544.790383] systemd[1]: Found dependency on var-www-mirror-debian.mount/start [ 604.763031] systemd[1]: Found dependency on mnt-gluster-gv0.mount/start [ 664.735658] systemd[1]: Found dependency on network.target/start [ 724.708286] systemd[1]: Found dependency on network.service/start [ 784.680916] systemd[1]: Found dependency on basic.target/start [ 844.653563] systemd[1]: Breaking ordering cycle by deleting job local-fs.targ et/start [ 904.626191] systemd[1]: Job local-fs.target/start deleted to break ordering c ycle starting with basic.target/start [ 904.627601] systemd[1]: Stopped Switch Root. [ 904.627681] systemd[1]: Stopping Switch Root. [ 904.627732] systemd[1]: Stopped target Switch Root. [ 904.627742] systemd[1]: Stopping Initrd File Systems. [ 904.627786] systemd[1]: Stopped target Initrd File Systems. [ 904.627794] systemd[1]: Stopping Initrd Root File System. [ 904.627837] systemd[1]: Stopped target Initrd Root File System. [ 904.627847] systemd[1]: Starting system-getty.slice. [ 904.639335] systemd[1]: Created slice system-getty.slice. [ 904.639349] systemd[1]: Starting Forward Password Requests to Wall Directory Watch. [ 904.639576] systemd[1]: Started Forward Password Requests to Wall Directory Watch. [ 904.639589] systemd[1]: Starting User and Session Slice. [ 904.639747] systemd[1]: Created slice User and Session Slice. [ 904.639759] systemd[1]: Starting Security Auditing Service... [ 904.640693] systemd[1]: Starting Collect Read-Ahead Data... [ 904.641314] systemd[1]: Starting Replay Read-Ahead Data... [ 904.641982] systemd[1]: Started Reconfigure the system on administrator request. [ 904.642009] systemd[1]: Starting Slices. [ 904.642071] systemd[1]: Reached target Slices. [ 904.642095] systemd[1]: Starting Delayed Shutdown Socket. [ 904.642871] systemd[1]: Listening on Delayed Shutdown Socket. ... The relevant line in my /etc/fstab: <primary.gluster.server>:gv0 /mnt/gluster/gv0 glusterfs defaults,_netdev 0 0 /mnt/gluster/gv0/debian /var/www/mirror/debian bind defaults,bind 0 0 Version-Release number of selected component (if applicable): systemd-208-9.fc20.x86_64 systemd-libs-208-9.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. add GlusterFS volume to /etc/fstab using _netdev mount option 2. add GlusterFS volume subdirectory to /etc/fstab using bind 3. reboot Actual results: system takes 15+ minutes to reboot. The delays pertain to the startup process. Expected results: system should reboot in a timely manner. Additional info: If I remove the _netdev option from mntops, the machine boots quickly, but I don't get my Gluster volume on boot if I do so. If I remove the bind mount of the subvolume (which is required because Gluster doesn't allow mounting subvolumes the way NFS does), the machine boots quickly. So it appears to be something with _netdev and bind on Fedora 20 that is causing an issue. This wasn't an issue in Fedora 18. I'm not sure if this was an issue in Fedora 19, as the machine was only Fedora 19 for one boot, when I immediately upgraded it to Fedora 20. I've been able to reproduce this on other Fedora 20 boxes w/out issue.
I guess systemd does not see the dependence between the GlusterFS volume and the bind mount. Please, bug 812826.
FWIW, I don't know if this problem still exists on the 3.4.x branch (it was present up until 3.4.6), but upgrading to 3.5.x fixed the problem. I suppose that it may have been the way GlusterFS 3.4.x registered itself with systemd as opposed to newer versions? I'm now running Fedora 3.6.3 on Fedora 21, and no problem there either.
(In reply to Chad Feller from comment #2) > I'm now running Fedora 3.6.3 on Fedora 21, and no problem there either. That should have read "I'm now running GlusterFS 3.6.3 on Fedora 21..."
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.