We use NIS to configure our automounts, but the automounts aren't being set up properly on some boots with some or all of the mounts missing. If NIS maps (or indeed any other network based maps) are being used, autofs shouldn't start until that service is available.
maybe this dependency should be expressed in the autofs initscripts LSB headers.
Then the LSB header of autofs should mention that ordering and systemd will honour it. Reassigning.
(In reply to comment #2) > Then the LSB header of autofs should mention that ordering and systemd will > honour it. Reassigning. There are a couple of problems with that. One is the that how to construct an LSB header is poorly documented to the point that I don't know how such dependencies should be correctly specified. The network and ypbind dependencies are already present in the autofs init script. The usual problem though is that NetworkManager doesn't wait until the network is online before continuing. You would think that if a dependency on the network was mentioned in the LSB header of a service then that would cause systems like NetworkManager to wait until the network was available when starting. Of course that's obviously easier said than done. Using nm-online to wait for network manager is not sufficient either because the yp bind service (or other service in which centralized automount maps are stored) may fail to start up for the same reason. The usual workaround I recommend is to set NETWORKWAIT=yes in /etc/sysconfig/network and if that isn't sufficient then also set NETWORKDELAY=<some sensible amount of time to wait>. Can you try this please Michael.
(In reply to comment #3) > The usual workaround I recommend is to set NETWORKWAIT=yes in > /etc/sysconfig/network and if that isn't sufficient then also > set NETWORKDELAY=<some sensible amount of time to wait>. This method is not applicable in F15. The F15 equivalent to NETWORKWAIT is: systemctl enable NetworkManager-wait-online.service
The NETWORKDELAY setting is however still applicable if you are using the traditional network script rather than NetworkManager and setting NETWORKDELAY=5 has so far made sure that autofs works afterwards.
Also experiencing this issue where autofs has no maps on F15 with NIS and NetworkManager. NETWORKWAIT=yes doesn't help as noted, adding NETWORKDELAY=15 seemed to slow the boot process, but did not have the desired effect. As an ugly hack, this worked: echo 'sleep 15; systemctl reload autofs.service' >> /etc/rc.local Looking forward to seeing a better fix! Thanks.
I don't understand why no-one has reported the result of trying what was suggested? Assuming NetworkManager is being used. If the NetworkManager init script is in use then the main setting to try is "NETWORKWAIT=yes" in /etc/sysconfig/network. If systemd is being used used then "systemctl enable NetworkManager-wait-online.service" is the setting to try (according to comment #4). If you see in the syslog that the network interface is not available when autofs starts then the setting used is not right. Also install the autofs package from here: https://admin.fedoraproject.org/updates/autofs-5.0.5-38.fc15
In my case I don't see this problem and I don't need either of the settings to wait for the network to come up. But I haven't checked it with the pre revision 38 package for a while now.
Sorry for not trying NetworkManager-wait-online.service, missed that. Unfortunately, no joy. Updated to autofs-5.0.5-38.fc15.x86_64 w/no change. Adding NETWORKWAIT=yes to /etc/sysconfig/network did not help. Some logs: # egrep -i network\|automount /var/log/boot.log Starting Network Manager... Starting Network Time Service... Started Network Time Service. Started Network Manager. Starting Network Manager Wait Online... Starting Network Manager Wait Online failed, see 'systemctl status NetworkManager-wait-online.service' for details. Starting LSB: Automounts filesystems on demand... Starting LSB: Mount and unmount network filesystems.... Started LSB: Automounts filesystems on demand. Started LSB: Mount and unmount network filesystems.. # systemctl status autofs.service NetworkManager-wait-online.service autofs.service - LSB: Automounts filesystems on demand Loaded: loaded (/etc/rc.d/init.d/autofs) Active: active (running) since Thu, 16 Jun 2011 13:53:36 -0400; 5min ago Process: 847 ExecStart=/etc/rc.d/init.d/autofs start (code=exited, status=0/SUCCESS) Main PID: 948 (automount) CGroup: name=systemd:/system/autofs.service └ 948 automount --pid-file /var/run/autofs.pid NetworkManager-wait-online.service - Network Manager Wait Online Loaded: loaded (/lib/systemd/system/NetworkManager-wait-online.service) Active: failed since Thu, 16 Jun 2011 13:53:34 -0400; 5min ago Process: 781 ExecStart=/usr/bin/nm-online -q -x --timeout=30 (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/NetworkManager-wait-online.service There is no 30-second pause during the boot, so it seems we're nowhere near the 30-second timeout in the ExecStart. This is easily duplicated in a vmware workstation where boots happen essentially with no disk activity (vm has 2gb, physical system has 12gb, SSD). I notice booting without rhgb, there is a 10-12 second delay after "Started LSB: The CUPS scheduler" which by pinging the vm, pings appear and the system continues to "Started LSB: Mount and unmount network filesystems.." when the network really becomes available. Note autofs is started before this delay, ypbind is started after. Will attach my boot.log.
Created attachment 505121 [details] boot.log
(In reply to comment #9) > Starting Network Manager Wait Online... > Starting Network Manager Wait Online failed, see 'systemctl status > NetworkManager-wait-online.service' for details. ... > NetworkManager-wait-online.service - Network Manager Wait Online > Loaded: loaded > (/lib/systemd/system/NetworkManager-wait-online.service) > Active: failed since Thu, 16 Jun 2011 13:53:34 -0400; 5min ago > Process: 781 ExecStart=/usr/bin/nm-online -q -x --timeout=30 > (code=exited, status=1/FAILURE) > CGroup: name=systemd:/system/NetworkManager-wait-online.service > > > There is no 30-second pause during the boot, so it seems we're nowhere near the > 30-second timeout in the ExecStart. This might be caused by bug 710502.
In bug 712504 (which appears to be a duplicate of this), the following was reported: This appears to be caused by incorrect dependency lines in /etc/init.d/autofs. Changing the lines # Required-Start: $network $ypbind # Required-Stop: $network $ypbind to # Required-Start: $network ypbind # Required-Stop: $network ypbind seems to correct the issue. From the LSB spec, dependencies starting with '$' should not be used by individual packages - and, indeed, ypbind's init script declares its service name as 'ypbind' without the '$'.
The fix in Comment #12 works for me. NETWORKWAIT not necessary. Also rebooted at least 4 times without NetworkManager-wait-online.service enabled. Thanks, Calvin!
The fix in Comment #12 doesn't works for me. I use the network init script. So far only systemctl restart ypbind.service systemctl restart rpcidmapd.service systemctl restart autofs.service in /etc/rc.local works. NETWORKWAIT=yes in /etc/sysconfig/network changed nothing.
Having this problem on Fedora 15 (with all current updates). The change mentioned in Comment #12 (fixing autofs init script) did not fix anything. It seemed both ypbind and autofs were starting long, long before the network came up. The command mentioned in Comment #4 (systemctl enable NetworkManager-wait-online.service) worked, but I had to also edit the NetworkManager-wait-online.service file and change the default hard-coded timeout of 30 to 60. The hard-coded 30 second delay there is really insufficient as there are many enterprise ethernet switches (which use Spanning Tree Protocol) that won't give you a connection for 30-60 seconds after you bring the link up.
*** Bug 740983 has been marked as a duplicate of this bug. ***
This issue appears to be fixed with the beta fedora 16 release. Can others confirm this?
No, it is broken in F16 as well. However the fix in Comment 12 also fixes F16.
Yep, it is still broken in F16 (and of course in F15). The fix in Comment #12 works as long as you use the NetworkManager and not /etc/init.d/network.
I'm seeing an interesting variant on this issue. - Installed current (as of this posting) Fedora 16. - Enabled ypbind (broadcast seems problematic, used fixed server IP) as per our environment including nsswitch.conf changes. - Setup /etc/init.d/autofs, NetworkManager-wait-online, & /etc/sysconfig/network as described above. - Restarted system - Logged in using NIS domain account (meaning non-local user) When logging in using console (Ctl-Alt-F3 rather then GUI) interface, the follow occurs: testbed login: george Password: <some_password> Last login: Mon Nov 21 11:18:12 on tty3 -- george: /home/dept/george: change directory failed: Permission denied Logging in with home = "/". testbed> pwd / testbed> cd testbed> pwd /home/dept/george testbed> Note that the NFS mounted home directory is root squashed. Any thoughts on this?
Pretty sure this particular issue belongs in another bug anyway are perhaps having selinux running and you forgot to do "setsebool -P use_nfs_home_dirs 1" ?(In reply to comment #20) > I'm seeing an interesting variant on this issue. > > - Installed current (as of this posting) Fedora 16. > - Enabled ypbind (broadcast seems problematic, used fixed server IP) as per > our environment including nsswitch.conf changes. > - Setup /etc/init.d/autofs, NetworkManager-wait-online, & > /etc/sysconfig/network as described above. > - Restarted system > - Logged in using NIS domain account (meaning non-local user) > > When logging in using console (Ctl-Alt-F3 rather then GUI) interface, the > follow occurs: > > testbed login: george > Password: <some_password> > Last login: Mon Nov 21 11:18:12 on tty3 > -- george: /home/dept/george: change directory failed: Permission denied > Logging in with home = "/". > > testbed> pwd > / > testbed> cd > testbed> pwd > /home/dept/george > testbed> > > Note that the NFS mounted home directory is root squashed. > > Any thoughts on this? Pretty sure this particular issue belongs in another bug anyway with limited info on this matter perhaps you have selinux running and you forgot to do "setsebool -P use_nfs_home_dirs 1" ? If that's not the case I'm pretty sure the maintainer wants know How the mount map look like? What the entry is in the master map? How the /etc/exports looks like? And what the server distribution and version are? +Anyone running F16 server with bash logins need to be aware of bug 752827
(In reply to comment #20) > I'm seeing an interesting variant on this issue. > > - Installed current (as of this posting) Fedora 16. > - Enabled ypbind (broadcast seems problematic, used fixed server IP) as per > our environment including nsswitch.conf changes. > - Setup /etc/init.d/autofs, NetworkManager-wait-online, & > /etc/sysconfig/network as described above. > - Restarted system > - Logged in using NIS domain account (meaning non-local user) > > When logging in using console (Ctl-Alt-F3 rather then GUI) interface, the > follow occurs: > > testbed login: george > Password: <some_password> > Last login: Mon Nov 21 11:18:12 on tty3 > -- george: /home/dept/george: change directory failed: Permission denied > Logging in with home = "/". Yes, you probably need to look a bit more at this. While the kernel is capable of sending through errno from user space daemon it still always sends ENOENT for mount fails. Once the thing is mounted autofs shouldn't be the one causing a problem. But we did have a problem with moving mounts in F16, resolved in revision ... umm ... 3 IIRC. But that will only be a problem for map entries that have multiple mounts, like the internal hosts map, for example. Simple indirect or direct mount map entries should be OK. If you want to go further you'll need to post a debug log. Ian
(In reply to comment #21) > Pretty sure this particular issue belongs in another bug anyway are perhaps > having selinux running and you forgot to do "setsebool -P use_nfs_home_dirs 1" > ?(In reply to comment #20) > > I'm seeing an interesting variant on this issue. > > > > - Installed current (as of this posting) Fedora 16. > > - Enabled ypbind (broadcast seems problematic, used fixed server IP) as per > > our environment including nsswitch.conf changes. > > - Setup /etc/init.d/autofs, NetworkManager-wait-online, & > > /etc/sysconfig/network as described above. > > - Restarted system > > - Logged in using NIS domain account (meaning non-local user) > > > > When logging in using console (Ctl-Alt-F3 rather then GUI) interface, the > > follow occurs: > > > > testbed login: george > > Password: <some_password> > > Last login: Mon Nov 21 11:18:12 on tty3 > > -- george: /home/dept/george: change directory failed: Permission denied > > Logging in with home = "/". > > > > testbed> pwd > > / > > testbed> cd > > testbed> pwd > > /home/dept/george > > testbed> > > > > Note that the NFS mounted home directory is root squashed. > > > > Any thoughts on this? > > Pretty sure this particular issue belongs in another bug anyway with limited > info on this matter perhaps you have selinux running and you forgot to do > "setsebool -P use_nfs_home_dirs 1" ? > > If that's not the case I'm pretty sure the maintainer wants know > How the mount map look like? > What the entry is in the master map? > How the /etc/exports looks like? > And what the server distribution and version are? > > +Anyone running F16 server with bash logins need to be aware of bug 752827 I can open a new bug if that is appropriate. To answer your specific questions: Selinux is disabled (as is iptables) The mount map is in the form of a NIS auto.home database, so: user server:/home/dept/& /etc/auto.master is unchanged as are all /etc/auto.* Note that /etc/nsswitch.conf has: automount: files nis The exports on the NFS server are simple: /home/dept *(rw,sync) The NFS server is: Red Hat Enterprise Linux ES release 4 (Nahant Update 5) I was not aware of the Bash issue; I'll check it out.
(In reply to comment #23) > > > > Pretty sure this particular issue belongs in another bug anyway with limited > > info on this matter perhaps you have selinux running and you forgot to do > > "setsebool -P use_nfs_home_dirs 1" ? > > > > If that's not the case I'm pretty sure the maintainer wants know > > How the mount map look like? > > What the entry is in the master map? > > How the /etc/exports looks like? > > And what the server distribution and version are? > > > > +Anyone running F16 server with bash logins need to be aware of bug 752827 > > I can open a new bug if that is appropriate. > > To answer your specific questions: > > Selinux is disabled (as is iptables) > > The mount map is in the form of a NIS auto.home database, so: > > user server:/home/dept/& > > /etc/auto.master is unchanged as are all /etc/auto.* > > Note that /etc/nsswitch.conf has: > > automount: files nis So you have something like /home auto.home within NIS auto.master, right? That's a simple indirect map so there shouldn't be a problem with that. But ensure you are running autofs revision 3 anyway. Recent work on F16 autofs has seen the package put through the usual Connectathon test suite which covers a wide range of map entry types and syntax. It doesn't use a plus included NIS map though, I'll need to setup a specific test for that. I'm not convinced there is a problem with it although I will setup the test when I get time. What kernel version are you using?
(In reply to comment #24) > (In reply to comment #23) > > > > > > Pretty sure this particular issue belongs in another bug anyway with limited > > > info on this matter perhaps you have selinux running and you forgot to do > > > "setsebool -P use_nfs_home_dirs 1" ? > > > > > > If that's not the case I'm pretty sure the maintainer wants know > > > How the mount map look like? > > > What the entry is in the master map? > > > How the /etc/exports looks like? > > > And what the server distribution and version are? > > > > > > +Anyone running F16 server with bash logins need to be aware of bug 752827 > > > > I can open a new bug if that is appropriate. > > > > To answer your specific questions: > > > > Selinux is disabled (as is iptables) > > > > The mount map is in the form of a NIS auto.home database, so: > > > > user server:/home/dept/& > > > > /etc/auto.master is unchanged as are all /etc/auto.* > > > > Note that /etc/nsswitch.conf has: > > > > automount: files nis > > So you have something like /home auto.home within NIS > auto.master, right? > > That's a simple indirect map so there shouldn't be a problem > with that. But ensure you are running autofs revision 3 anyway. > > Recent work on F16 autofs has seen the package put through > the usual Connectathon test suite which covers a wide range > of map entry types and syntax. > > It doesn't use a plus included NIS map though, I'll need > to setup a specific test for that. I'm not convinced there > is a problem with it although I will setup the test when I > get time. > > What kernel version are you using? Sorry, forgot that detail... yes NIS auto.home is as you say: /home/dept auto_home /home/dept1 auto_home and so forth. Autofs revision 3? I'm unsure what you are asking for here. Note that standard F16 RPM is in use: [root@pxei log]# rpm -q -a | egrep autofs autofs-5.0.6-3.fc16.x86_64 Ditto on the x86_64 kernel: [root@pxei log]# uname -a Linux pxei 3.1.1-1.fc16.x86_64 #1 SMP Fri Nov 11 21:47:56 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Unrelated to the problem but worth mentioning; we are trying to migrate away from NIS (and NFS to a lesser extent) here, but given our current user base that will be a multi-year process. Thank you for your interest!
(In reply to comment #25) snip ... > > > > > > /etc/auto.master is unchanged as are all /etc/auto.* > > > > > > Note that /etc/nsswitch.conf has: > > > > > > automount: files nis > > > > So you have something like /home auto.home within NIS > > auto.master, right? > > > > That's a simple indirect map so there shouldn't be a problem > > with that. But ensure you are running autofs revision 3 anyway. > > > > Recent work on F16 autofs has seen the package put through > > the usual Connectathon test suite which covers a wide range > > of map entry types and syntax. > > > > It doesn't use a plus included NIS map though, I'll need > > to setup a specific test for that. I'm not convinced there > > is a problem with it although I will setup the test when I > > get time. > > > > What kernel version are you using? > > Sorry, forgot that detail... yes NIS auto.home is as you say: > > /home/dept auto_home > /home/dept1 auto_home > > and so forth. Right. > > Autofs revision 3? I'm unsure what you are asking for here. > Note that standard F16 RPM is in use: > > [root@pxei log]# rpm -q -a | egrep autofs > autofs-5.0.6-3.fc16.x86_64 Yeah, you do have revision 3, I always refer to the -3, before the .fc16 as the package revision. > > Ditto on the x86_64 kernel: > > [root@pxei log]# uname -a > Linux pxei 3.1.1-1.fc16.x86_64 #1 SMP Fri Nov 11 21:47:56 UTC 2011 x86_64 > x86_64 x86_64 GNU/Linux That looks like the kernel that was installed when I installed the recent F16 release the other day. There aren't any problems I'm aware of with that kernel. I'll setup an included map NIS test and see if I can reproduce the problem. If I can't and you've checked everything we'll need to get a debug log. Although I think we will need a new bug to track the investigation since this doesn't look anything like this bug.
(In reply to comment #26) > (In reply to comment #25) > > snip ... > > > > > > > > > /etc/auto.master is unchanged as are all /etc/auto.* > > > > > > > > Note that /etc/nsswitch.conf has: > > > > > > > > automount: files nis > > > > > > So you have something like /home auto.home within NIS > > > auto.master, right? > > > > > > That's a simple indirect map so there shouldn't be a problem > > > with that. But ensure you are running autofs revision 3 anyway. > > > > > > Recent work on F16 autofs has seen the package put through > > > the usual Connectathon test suite which covers a wide range > > > of map entry types and syntax. > > > > > > It doesn't use a plus included NIS map though, I'll need > > > to setup a specific test for that. I'm not convinced there > > > is a problem with it although I will setup the test when I > > > get time. > > > > > > What kernel version are you using? > > > > Sorry, forgot that detail... yes NIS auto.home is as you say: > > > > /home/dept auto_home > > /home/dept1 auto_home > > > > and so forth. > > Right. > > > > > Autofs revision 3? I'm unsure what you are asking for here. > > Note that standard F16 RPM is in use: > > > > [root@pxei log]# rpm -q -a | egrep autofs > > autofs-5.0.6-3.fc16.x86_64 > > Yeah, you do have revision 3, I always refer to the -3, > before the .fc16 as the package revision. > > > > > Ditto on the x86_64 kernel: > > > > [root@pxei log]# uname -a > > Linux pxei 3.1.1-1.fc16.x86_64 #1 SMP Fri Nov 11 21:47:56 UTC 2011 x86_64 > > x86_64 x86_64 GNU/Linux > > That looks like the kernel that was installed when I installed > the recent F16 release the other day. There aren't any problems > I'm aware of with that kernel. > > I'll setup an included map NIS test and see if I can reproduce > the problem. If I can't and you've checked everything we'll need > to get a debug log. Although I think we will need a new bug to > track the investigation since this doesn't look anything like > this bug. Do you want me to open the new bug? Or would you prefer to do that internally?
(In reply to comment #27) > (In reply to comment #26) > > > > I'll setup an included map NIS test and see if I can reproduce > > the problem. If I can't and you've checked everything we'll need > > to get a debug log. Although I think we will need a new bug to > > track the investigation since this doesn't look anything like > > this bug. > > Do you want me to open the new bug? > Or would you prefer to do that internally? You know how best how to describe the problem, and you would also be the owner of the bug, so it would be best if you opened the bug.
(In reply to comment #28) > (In reply to comment #27) > > (In reply to comment #26) > > > > > > I'll setup an included map NIS test and see if I can reproduce > > > the problem. If I can't and you've checked everything we'll need > > > to get a debug log. Although I think we will need a new bug to > > > track the investigation since this doesn't look anything like > > > this bug. > > > > Do you want me to open the new bug? > > Or would you prefer to do that internally? > > You know how best how to describe the problem, and you > would also be the owner of the bug, so it would be best > if you opened the bug. I opened Bug #756123 as requested. Thanks for the support!
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached 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 to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping