Bug 712504 - autofs is started before ypbind in Fedora 15
Summary: autofs is started before ypbind in Fedora 15
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: autofs
Version: 15
Hardware: i686
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Ian Kent
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-10 19:45 UTC by Nick Bowler
Modified: 2012-03-21 02:39 UTC (History)
13 users (show)

Fixed In Version: autofs-5.0.5-39.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-21 02:39:51 UTC


Attachments (Terms of Use)

Description Nick Bowler 2011-06-10 19:45:30 UTC
Description of problem:
In a fresh install of Fedora 15, autofs is started before ypbind at boot.  The
automount daemon subsequently fails to retrieve auto.master over NIS for
obvious reasons, and thus automounting doesn't work.

This all worked in Fedora 14 and all previous versions back to (at least)
Fedora Core 4.

The symlinks appear to be in a sane order in /etc/rc{3,5}.d:

  /etc/rc5.d/S26ypbind
  /etc/rc5.d/S28autofs

yet they're not started in the right order, as evidenced by the following
excerpt from /var/log/messages:

   Jun 10 15:33:53 ulna rpc.statd[935]: Version 1.2.3 starting
   Jun 10 15:33:53 ulna sm-notify[936]: Version 1.2.3 starting
   Jun 10 15:33:54 ulna kernel: [   23.116657] RPC: Registered udp transport module.
   Jun 10 15:33:54 ulna kernel: [   23.116664] RPC: Registered tcp transport module.
   Jun 10 15:33:54 ulna kernel: [   23.116668] RPC: Registered tcp NFSv4.1 backchannel transport module.
   Jun 10 15:33:54 ulna automount[971]: lookup_init:136: lookup(yp): map auto.master: Local domain name not set
   Jun 10 15:33:54 ulna automount[971]: lookup_init:136: lookup(yp): map auto_master: Local domain name not set
   Jun 10 15:33:54 ulna kernel: [   23.705678] skge 0000:02:00.0: p1p1: Link is up at 1000 Mbps, full duplex, flow control none
   Jun 10 15:33:58 ulna dhclient[737]: DHCPDISCOVER on p1p1 to 255.255.255.255 port 67 interval 8
   Jun 10 15:33:58 ulna dhclient[737]: DHCPOFFER from 192.168.9.1
   Jun 10 15:33:58 ulna dhclient[737]: DHCPREQUEST on p1p1 to 255.255.255.255 port 67
   Jun 10 15:33:58 ulna dhclient[737]: DHCPACK from 192.168.9.1
   Jun 10 15:33:58 ulna dhclient[737]: bound to 192.168.9.40 -- renewal in 5964 seconds.
   Jun 10 15:33:58 ulna NetworkManager[626]: <info> (p1p1): DHCPv4 state changed preinit -> bound
   Jun 10 15:33:58 ulna NetworkManager[626]: <info> Activation (p1p1) Stage 4 of 5 (IP4 Configure Get) scheduled...
   Jun 10 15:33:58 ulna NetworkManager[626]: <info> Activation (p1p1) Stage 4 of 5 (IP4 Configure Get) started...
   Jun 10 15:33:58 ulna NetworkManager[626]: <info>   address 192.168.9.40
   Jun 10 15:33:58 ulna NetworkManager[626]: <info>   prefix 24 (255.255.255.0)
   Jun 10 15:33:58 ulna NetworkManager[626]: <info>   gateway 192.168.9.1
   Jun 10 15:33:58 ulna NetworkManager[626]: <info>   nameserver '192.168.8.21'
   Jun 10 15:33:58 ulna NetworkManager[626]: <info>   nameserver '192.168.8.25'
   Jun 10 15:33:58 ulna NetworkManager[626]: <info>   domain name 'ellipticsemi.com'
   Jun 10 15:33:58 ulna NetworkManager[626]: <info>   NIS domain 'ellipticsemi.com'
   Jun 10 15:33:58 ulna NetworkManager[626]: <info>   nis '192.168.9.60'
   Jun 10 15:33:58 ulna NetworkManager[626]: <info> Activation (p1p1) Stage 5 of 5 (IP Configure Commit) scheduled...
   Jun 10 15:33:58 ulna NetworkManager[626]: <info> Activation (p1p1) Stage 4 of 5 (IP4 Configure Get) complete.
   Jun 10 15:33:58 ulna NetworkManager[626]: <info> Activation (p1p1) Stage 5 of 5 (IP Configure Commit) started...
   Jun 10 15:33:58 ulna avahi-daemon[627]: Joining mDNS multicast group on interface p1p1.IPv4 with address 192.168.9.40.
   Jun 10 15:33:58 ulna avahi-daemon[627]: New relevant interface p1p1.IPv4 for mDNS.
   Jun 10 15:33:58 ulna avahi-daemon[627]: Registering new address record for 192.168.9.40 on p1p1.IPv4.
   Jun 10 15:33:59 ulna NetworkManager[626]: <info> (p1p1): device state change: ip-config -> activated (reason 'none') [70 100 0]
   Jun 10 15:33:59 ulna NetworkManager[626]: <info> Policy set 'Wired connection 1' (p1p1) as default for IPv4 routing and DNS.
   Jun 10 15:33:59 ulna NetworkManager[626]: <info> Activation (p1p1) successful, device activated.
   Jun 10 15:33:59 ulna dbus-daemon: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
   Jun 10 15:33:59 ulna NetworkManager[626]: <info> Activation (p1p1) Stage 5 of 5 (IP Configure Commit) complete.
   Jun 10 15:33:59 ulna dbus-daemon: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
   Jun 10 15:34:01 ulna ypbind: NIS domain: ellipticsemi.com, NIS server: yipee.ellipticsemi.com

Running /etc/init.d/autofs restart after the system boots corrects the issue,
but this can be a challenge because user logins won't work properly without
automount (as user home directories don't get mounted).

Version-Release number of selected component (if applicable):
autofs.i686                              1:5.0.5-35.fc15                @fedora
ypbind.i686                              3:1.32-8.fc15.1                @fedora

How reproducible:
Happens every boot.

Steps to Reproduce:
0. Configure your network and system to have auto.master (or similar) available
   over NIS.
1. chkconfig --level 35 ypbind on
2. chkconfig --level 35 autofs on
3. reboot
  
Actual results:
Autofs is started before ypbind, and fails to retrieve auto.master.

Expected results:
Autofs is started after ypbind, and works.

Additional info:
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.

Comment 1 Bill Nottingham 2011-06-13 18:45:28 UTC
Moving to autofs.

Comment 2 Ian Kent 2011-06-14 03:35:38 UTC
Before we go further can you try autofs revision 38 please.

You can get revision 38 at:
http://kojipkgs.fedoraproject.org/packages/autofs/5.0.5/38.fc15

or wait until it is pushed to the testing repo.

Comment 3 Nick Bowler 2011-06-16 18:49:29 UTC
(In reply to comment #2)
> Before we go further can you try autofs revision 38 please.
> 
> You can get revision 38 at:
> http://kojipkgs.fedoraproject.org/packages/autofs/5.0.5/38.fc15
> 
> or wait until it is pushed to the testing repo.

Just upgraded to the following version:
autofs.i686        1:5.0.5-38.fc15         @updates-testing

and the issue persists.

Comment 4 Knut Omang 2011-07-01 17:13:49 UTC
(In reply to comment #3)
I have seen the same problem with 1:5.0.5-38.fc15 of autofs and the solution of changing 

  # Required-Start: $network $ypbind
  # Required-Stop: $network $ypbind

to

  # Required-Start: $network ypbind
  # Required-Stop: $network ypbind

seems to have solved it for me too - reading the Fedora documentation I did not find any mentioning of what the $ signs mean in this context but judging from 

http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/facilname.html

Nick's solution seems to be the correct fix for the problem?

I would suggest adding a section about the 'reserved special facilities' in the fedora docs since it seems to have confused others as well: 

ypbind currently uses 

# Required-Start: $local_fs $remote_fs $network $rpcbind

and as far as I understand rpcbind is also not a 'special facility' ?

Comment 5 JM 2011-11-10 16:14:23 UTC
I think this is a duplicate of Bug 709637 (?)

Comment 6 JM 2011-11-16 23:38:50 UTC
Is there a change that this bug gets fixed in F16? It's very annoying and according to Comment #3 the fix would be simple.

Comment 7 Stephen Tweedie 2011-11-28 21:25:41 UTC
The fix described here is still needed in F16.

I've checked with "systemctl dot", and with the "$ypbind" form autofs has a dependency of "ypbind.target", which is plainly wrong.  With s/$ypbind/ypbind/, the dependency is correctly on "ypbind.service".

This is a simple fix, but autofs over NIS is completely non-functional without it; can we get it applied soon, please?

(The fix is necessary but not sufficient, unfortunately; we also need a fix for ypbind, to wait for the service to be functional before marking it ready, which I'll report separately.  So "systemctl dot" is a better way to be sure that this particular fix is working.)

Comment 8 Ian Kent 2011-11-29 00:08:47 UTC
(In reply to comment #7)
> The fix described here is still needed in F16.
> 
> I've checked with "systemctl dot", and with the "$ypbind" form autofs has a
> dependency of "ypbind.target", which is plainly wrong.  With s/$ypbind/ypbind/,
> the dependency is correctly on "ypbind.service".

Ahh .. a common sense reasoned observation at last.

> 
> This is a simple fix, but autofs over NIS is completely non-functional without
> it; can we get it applied soon, please?

Yes, I'll try to get it done today.

Ian

Comment 9 Ian Kent 2011-11-30 08:46:12 UTC
Can we give this scratch build a try please.

It can be found at:
http://people.redhat.com/~ikent/autofs-5.0.5-39.fc15

Comment 10 Nick Bowler 2011-11-30 14:37:58 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > I've checked with "systemctl dot", and with the "$ypbind" form autofs has a
> > dependency of "ypbind.target", which is plainly wrong.  With s/$ypbind/ypbind/,
> > the dependency is correctly on "ypbind.service".
> 
> Ahh .. a common sense reasoned observation at last.

"At last"?  I was sure that I mentioned that s/$ypbind/ypbind/ corrects the issue in the original report...

(In reply to comment #9)
> Can we give this scratch build a try please.
> 
> It can be found at:
> http://people.redhat.com/~ikent/autofs-5.0.5-39.fc15

Unsurprisingly, since this version includes the aforementioned fix, it
works.

Comment 11 Ian Kent 2011-12-01 07:40:06 UTC
(In reply to comment #10)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > I've checked with "systemctl dot", and with the "$ypbind" form autofs has a
> > > dependency of "ypbind.target", which is plainly wrong.  With s/$ypbind/ypbind/,
> > > the dependency is correctly on "ypbind.service".
> > 
> > Ahh .. a common sense reasoned observation at last.
> 
> "At last"?  I was sure that I mentioned that s/$ypbind/ypbind/ corrects the
> issue in the original report...

Yes, but what you may not be aware of is that this has gone on
for quite a long time and I have made changes along the way based
on people saying "this appears to fix the problem" and it actually
didn't.

I didn't know what the root cause of this was but Stephen offered
the observation of what was happening within systemd which made
sense.

It was (and possibly still will be) frustrating for you but it
was frustrating form me well before.

Anyway, that's for checking the change, I'll commit the change
and request a push and update the other distros.

Ian

Comment 12 Ian Kent 2011-12-01 07:41:45 UTC
(In reply to comment #11)
> 
> Anyway, that's for checking the change, I'll commit the change
> and request a push and update the other distros.

That should be thanks, not that's.

> 
> Ian

Comment 13 Fedora Update System 2011-12-02 09:22:47 UTC
autofs-5.0.5-39.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/autofs-5.0.5-39.fc15

Comment 14 Fedora Update System 2011-12-02 10:39:55 UTC
autofs-5.0.6-4.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/autofs-5.0.6-4.fc16

Comment 15 Fedora Update System 2011-12-04 02:31:08 UTC
Package autofs-5.0.5-39.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing autofs-5.0.5-39.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-16695/autofs-5.0.5-39.fc15
then log in and leave karma (feedback).

Comment 16 Stephen Tweedie 2011-12-05 14:30:11 UTC
Thanks, f16 packages from koji fix this part of the problem for me.  I'll pursue the other problems separately (ypbind and rpcbind both need initscripts/systemd fixes too.)

Comment 17 Fedora Update System 2012-01-07 22:56:31 UTC
autofs-5.0.6-4.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 18 Fedora Update System 2012-03-21 02:39:51 UTC
autofs-5.0.5-39.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.


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