Description of problem: I am using autofs with home nis maps. If I reboot the computer, the nis maps are not recognized by autofs. I have to restart autofs from root account before login as a user: /etc/init.d/autofs restart My /etc/auto.master looks like: /misc /etc/auto.misc /net -hosts +auto.master In principle autofs is started after nis: #ls -l /etc/rc5.d/S* S27ypbind S28autofs but it looks like autofs does not "wait" to ypbind to actually connect to the server. How reproducible: Always, at boot time Steps to Reproduce: 1. Install both ypbind and autofs (yum install ypbind autofs) 2. Configure autofs to a NIS map (for instance +auto.master in file /etc/auto.master) 3. Restart the computer 4. Try to use any of the NIS maps (in my case a user home directory) either login in or using "cd" from root account. Actual results: The mount map is not mounted Additional info: "/etc/init.d/autofs restart" as root after reboot is a workaround that solves the problem.
(In reply to comment #0) > Description of problem: > > I am using autofs with home nis maps. If I reboot the computer, the nis maps > are not recognized by autofs. I have to restart autofs from root account before > login as a user: > /etc/init.d/autofs restart > > My /etc/auto.master looks like: > /misc /etc/auto.misc > /net -hosts > +auto.master > > In principle autofs is started after nis: > #ls -l /etc/rc5.d/S* > S27ypbind S28autofs > > but it looks like autofs does not "wait" to ypbind to actually connect to the > server. We've had a similar problem reported recently and I did what I could within the init script. I also started work on improving the way autofs handles not being able to acquire the master map at startup but haven't been able to return to that for a while. I'll do that as soon as I get a chance. In theory autofs shouldn't have to worry about this but ypbind can't wait too long, possibly forever, at startup either.
Any chance on getting this fix for Fedora 14? This bug prevents us from deploying in the future a number of Fedora machines, since the automounter has to be manually restarted by root every time. Regards
(In reply to comment #2) > Any chance on getting this fix for Fedora 14? This bug prevents us from > deploying in the future a number of Fedora machines, since the automounter has > to be manually restarted by root every time. > Regards It's way too late for F14 initial release but I should have something for you to test soonish. If all goes well I could get it out as an update soon after the F14 release.
I have added some patches to the Rawhide autofs package. Included is a patch that might help with the issue your seeing. If you are willing you could build the new package locally and try it out, other wise you'll need to wait until I get to making a test build for F-14. The Rawhide source package can be found here: http://kojipkgs.fedoraproject.org/packages/autofs/5.0.5/32.fc15/src
(In reply to comment #0) > Description of problem: > > I am using autofs with home nis maps. If I reboot the computer, the nis maps > are not recognized by autofs. I have to restart autofs from root account before > login as a user: > /etc/init.d/autofs restart > > My /etc/auto.master looks like: > /misc /etc/auto.misc > /net -hosts > +auto.master > > In principle autofs is started after nis: > #ls -l /etc/rc5.d/S* > S27ypbind S28autofs > > but it looks like autofs does not "wait" to ypbind to actually connect to the > server. But when ypbind is started it waits to bind to a NIS server. If it fails to bind the ypbind service is shutdown. So what is really happening? Ian
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
(In reply to comment #0) > Description of problem: > > I am using autofs with home nis maps. If I reboot the computer, the nis maps > are not recognized by autofs. I have to restart autofs from root account before > login as a user: > /etc/init.d/autofs restart > > My /etc/auto.master looks like: > /misc /etc/auto.misc > /net -hosts > +auto.master > > In principle autofs is started after nis: > #ls -l /etc/rc5.d/S* > S27ypbind S28autofs > > but it looks like autofs does not "wait" to ypbind to actually connect to the > server. > > > > How reproducible: > > Always, at boot time > > Steps to Reproduce: > 1. Install both ypbind and autofs (yum install ypbind autofs) > 2. Configure autofs to a NIS map (for instance +auto.master in file > /etc/auto.master) > 3. Restart the computer > 4. Try to use any of the NIS maps (in my case a user home directory) either > login in or using "cd" from root account. > > Actual results: > The mount map is not mounted > > Additional info: > > "/etc/init.d/autofs restart" as root after reboot is a workaround that solves > the problem. As an arguably better work around you can try setting "NISTIMEOUT=120" or some larger value in /etc/sysconfig/ypbind This value is used in /etc/init.d/ypbind to determine how long to wait for NIS to bind to the domain. A larger value increases the likely hood of NIS binding before the script completes and so increases the likely hood of the NIS auto mount map being available to autofs later (next) in the boot sequence. Alex Owen
(In reply to comment #7) > (In reply to comment #0) > > Description of problem: > > > > I am using autofs with home nis maps. If I reboot the computer, the nis maps > > are not recognized by autofs. I have to restart autofs from root account before > > login as a user: > > /etc/init.d/autofs restart > > > > My /etc/auto.master looks like: > > /misc /etc/auto.misc > > /net -hosts > > +auto.master > > > > In principle autofs is started after nis: > > #ls -l /etc/rc5.d/S* > > S27ypbind S28autofs > > > > but it looks like autofs does not "wait" to ypbind to actually connect to the > > server. > > > > > > > > How reproducible: > > > > Always, at boot time > > > > Steps to Reproduce: > > 1. Install both ypbind and autofs (yum install ypbind autofs) > > 2. Configure autofs to a NIS map (for instance +auto.master in file > > /etc/auto.master) > > 3. Restart the computer > > 4. Try to use any of the NIS maps (in my case a user home directory) either > > login in or using "cd" from root account. > > > > Actual results: > > The mount map is not mounted > > > > Additional info: > > > > "/etc/init.d/autofs restart" as root after reboot is a workaround that solves > > the problem. > > As an arguably better work around you can try setting "NISTIMEOUT=120" or some > larger value in > /etc/sysconfig/ypbind > > This value is used in /etc/init.d/ypbind to determine how long to wait for NIS > to bind to the domain. A larger value increases the likely hood of NIS binding > before the script completes and so increases the likely hood of the NIS auto > mount map being available to autofs later (next) in the boot sequence. > Alex Owen Also in /etc/init.d/ypbind would be more robust to change the timeout line to: # the following fixes problems with the init scripts continuing # even when we are really not bound yet to a server, and then things # that need NIS fail. timeout=$NISTIMEOUT firsttime=1 SECONDS=0 That is change: timeout=10 to timeout=$NISTIMEOUT My experience is that the 10 seconds is too short a time and rather than introduce a separate timeout variable why not reuse the $NISTIMEOUT variable? Perhaps someone more bugzilla astute can clone this report to the ypbind package! Hope that helps Alex Owen
Hi! Sorry for not commenting so far, I was sometime away. To comment #5: indeed, I expected that to be the behaviour, that autofs would wait for ypbind. But it seems not to be the case.. I have checked that other autofs maps not retrieved from NIS are working properly (so autofs indeed starts). Also ypbind works properly, since "ypcat passwd" works. #7, #8: Thanks for the tip! I have just updated my configuration. As soon as I am able to reboot I will tell you if that solution works. Regards
It seems that the workaround suggested in #7 and #8 works. Could that be implemented in a future version of autofs? Regards
I'm seeing similar symptoms on f14 where a ypbind startup failure (I'm betting either a delayed/asynchronous NM startup and/or DNS not being ready yet) yields autofs maps to fail too.
Are you using NetworkManager to manage your network interfaces?
Yes (? I assume that's the default?)
Fwiw, I confirmed it's seems to be dns fail. Putting my nis server's ip address into /etc/yp.conf instead of DNS name seems to make the problem go away.
(In reply to comment #13) > Yes (? I assume that's the default?) If you are put "NETWORKWAIT=yes" into /etc/sysconfig/network. If that doesn't do it the also add "NETWORKDELAY=<seconds>" where seconds is enough of a delay for your needs. I think only the first config entry should be needed.
Thanks! That workaround works like a charm.
There are problems with this in Fedora 15 as well. To get this working I changed the broken code in /etc/init.d/ypbind that waits for ypwhich to start working with the code from Red Hat 5: # the following fixes problems with the init scripts continuing # even when we are really not bound yet to a server, and then things # that need NIS fail. echo -n $"Listening for an NIS domain server." for (( times = 1; times < $NISTIMEOUT; times++ )); do /usr/sbin/rpcinfo -p | LC_ALL=C fgrep -q ypbind && ypwhich > /dev/null 2>&1 retval=$? if [ $retval -eq 0 ]; then break; fi sleep 1 echo -n "." done It was also necessary to change the "Provides" line in /etc/init.d/ypbind to remove "$": # Provides: ypbind and in /etc/init.d/autofs also remove "$" from these lines thus: # Required-Start: $network ypbind # Required-Stop: $network ypbind
(In reply to comment #17) > To get this working I changed the broken code in /etc/init.d/ypbind that waits > for ypwhich to start working with the code from Red Hat 5: Graham, can you, please, tell me what was broken in /etc/init.d/ypbind script in F15 or what where your reasons to change this script? > It was also necessary to change the "Provides" line in /etc/init.d/ypbind to > remove "$": I'm wondering how "$" got to this line, while it is not there in original package. Have you added it there manually?
Jan, /etc/init.d/ypbind contains: timeout=10 firsttime=1 SECONDS=0 while [ $SECONDS -lt $timeout ]; do if /usr/sbin/rpcinfo -p | LC_ALL=C fgrep -q ypbind then if [ $firsttime -eq 1 ]; then # reset timeout timeout=$NISTIMEOUT firsttime=0 fi /usr/bin/ypwhich > /dev/null 2>&1 retval=$? if [ $retval -eq 0 ]; then break; fi fi sleep 2 echo -n "." done The variable "SECONDS" is not incremented anywhere in the loop. There seems to be no reason for "timeout" to be set to 10 initially instead of "$NISTIMEOUT". The RHEL5 code gets this right. As for "Provides: ypbind" you are right, either myself or my colleague must have wrongly added a "$", sorry. I think the "$" in "$ypbind" in /etc/init.d/autofs is wrong though, removing that seems to fix the problem and cause automount to wait until ypbind has started properly.
(In reply to comment #19) > The variable "SECONDS" is not incremented anywhere in the loop. $SECONDS is a kind of magic variable (for more info see http://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html), it should ensure that testing will last exactly 10s, even if e.g. ypwhich waits 5s every-time (in that case your workaround will last 10 * 5s + 10s). > There seems to > be no reason for "timeout" to be set to 10 initially instead of "$NISTIMEOUT". > The RHEL5 code gets this right. Well, I'm not sure about the reason right now, but I believe there was a use case, which this was implemented for. What's worth for me now - it works. > I think the "$" in "$ypbind" in /etc/init.d/autofs is wrong though, removing > that seems to fix the problem and cause automount to wait until ypbind has > started properly. That's right.
(In reply to comment #20) > (In reply to comment #19) > > The variable "SECONDS" is not incremented anywhere in the loop. > > $SECONDS is a kind of magic variable (for more info see > http://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html), it Interesting, thank you for putting me right on that.
I am experiencing this as well on real hardware (not virtual). What I discovered was ypbind was not in the 'rpcinfo -p' output for 24 to 26 seconds, and thus, the default "timeout=10" expired, ignoring any setting of NISTIMEOUT in /etc/sysconfig/ypbind. To see this, just add an "else echo -n @" above the "fi; sleep 2" lines. Fixing the initial timeout, coupled with the $ypbind -> ypbind fix in autofs's init script, has me automounting reliably on bootup, verified by adding this one-liner to /etc/rc.local: while ! ls /home/schanzle; do sleep 1; echo -n .; done; sleep 10 Note that replicating this on vmware workstation I did not have long pauses waiting for ypbind to register with rpcinfo. I'll attach a patch with these visible improvements (perhaps change the @ to , is more appealing) and logging the # of seconds it took to bind, plus removing a couple extra forks.
Created attachment 530936 [details] proposed patch that handles long rpcinfo call (In reply to comment #22) > What I discovered was ypbind was not in the 'rpcinfo -p' output for 24 to 26 > seconds, and thus, the default "timeout=10" expired, ignoring any setting of > NISTIMEOUT in /etc/sysconfig/ypbind. Yes, in this use case the script won't work properly, thanks for the point. It seems to me that the hard-coded 10s value in timeout ensures that we check the ypbind status even if a user sets NISTIMEOUT=0. If we just set timeout=$NISTIMEOUT and NISTIMEOUT will be changed to 0 by a user then we won't check the ypbind at all, which is wrong from my POV. The attached patch should handle this issue correctly.
ypbind-1.32-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/ypbind-1.32-2.fc14
ypbind-1.32-8.fc15.2 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/ypbind-1.32-8.fc15.2
ypbind-1.33-9.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/ypbind-1.33-9.fc16
ypbind-1.32-8.fc15.3 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/ypbind-1.32-8.fc15.3
ypbind-1.32-3.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/ypbind-1.32-3.fc14
Package ypbind-1.32-3.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ypbind-1.32-3.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-16216/ypbind-1.32-3.fc14 then log in and leave karma (feedback).
Since I reported the bug I have upgraded to Fedora 15. I have upgraded to proposed update ypbind-1.32-8.fc15.3 but the bug is still there: I have to manually restart autofs once the system has been rebooted to be able to login in my NIS account. So, any ideas on how to fix this in Fedora 15? Regards, Enrique
Enrique, can you please boot with "log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg" and attach the output of the "dmesg" command here?
Created attachment 539568 [details] Output of dmesg command
Hi, I have added the output of dmesg, as requested. Regards
Enrique, it seems autofs starts a bit earlier than it should, which can be related to bug #712504. Can you try it with the new autofs, please?
(In reply to comment #34) > Enrique, it seems autofs starts a bit earlier than it should, which can be > related to bug #712504. Can you try it with the new autofs, please? I mean autofs-5.0.5-39.fc15 from updates-testing..
ypbind-1.33-9.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
ypbind-1.32-8.fc15.3 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
ypbind-1.32-3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
Hi, well the bug is already closed, but just to report that with both autofs-5.0.5-39.fc15 and ypbind-1.32-8.fc15.3 everything works fine. Thank you very much for fixing this!