This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 475002 - autofs gets started before NIS at boot time
autofs gets started before NIS at boot time
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
11
All Linux
low Severity high
: ---
: ---
Assigned To: Ian Kent
Fedora Extras Quality Assurance
:
: 476934 488774 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-06 10:33 EST by Dave Mack
Modified: 2010-06-28 06:54 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 06:54:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Dave Mack 2008-12-06 10:33:05 EST
Description of problem:
In the current version of Rawhide, autofs and ypbind have the same startup value, so autofs gets started first. If automount maps are being provided via NIS, this results in breakage. Fix is to increment autofs start to higher value than ypbind start value (currently 28).

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Ian Kent 2008-12-08 11:00:16 EST
(In reply to comment #0)
> Description of problem:
> In the current version of Rawhide, autofs and ypbind have the same startup
> value, so autofs gets started first. If automount maps are being provided via
> NIS, this results in breakage. Fix is to increment autofs start to higher value
> than ypbind start value (currently 28).

Oops, will do.
Ian
Comment 2 Jeffrey Moyer 2008-12-08 11:06:49 EST
Umm, hold on a second.  In CVS, ypbind's init script lists 27.  Did you change this locally?
Comment 3 Ian Kent 2008-12-09 00:24:01 EST
Looking at the CVS checkouts of ypserv, ypbind and autofs I see
that:
ypserv (and ypxfrd) is set to start at order 26.
ypbind is set to start at order 27.
autofs is set to start at order 28.

which looks fine to me and I haven't changed the run order of
autofs in a long, long time.

So, this is looking like NOTABUG to me.

Ian
Comment 4 Dave Mack 2008-12-11 10:52:29 EST
(In reply to comment #2)
> Umm, hold on a second.  In CVS, ypbind's init script lists 27.  Did you change
> this locally?

At the time I checked this, both ypbind and autofs started at 28. I chose to change autofs to 29 to get things working. It appears that ypbind's start value has been reduced.
Comment 5 Dave Mack 2008-12-11 10:54:35 EST
(In reply to comment #3)
> Looking at the CVS checkouts of ypserv, ypbind and autofs I see
> that:
> ypserv (and ypxfrd) is set to start at order 26.
> ypbind is set to start at order 27.
> autofs is set to start at order 28.
> 
> which looks fine to me and I haven't changed the run order of
> autofs in a long, long time.
> 
> So, this is looking like NOTABUG to me.
> 
> Ian

Not quite notabug. In addition to the earlier problem, autofs starts in runlevel 2 while ypbind starts in runlevel 3:

[dmack@citrine(Linux)]:/etc/init.d
> chkconfig --list autofs
autofs          0:off   1:off   2:on    3:on    4:on    5:on    6:off
[dmack@citrine(Linux)]:/etc/init.d
> chkconfig --list ypbind
ypbind          0:off   1:off   2:off   3:on    4:on    5:on    6:off
Comment 6 Ian Kent 2008-12-14 17:21:49 EST
(In reply to comment #5)
> (In reply to comment #3)
> > Looking at the CVS checkouts of ypserv, ypbind and autofs I see
> > that:
> > ypserv (and ypxfrd) is set to start at order 26.
> > ypbind is set to start at order 27.
> > autofs is set to start at order 28.
> > 
> > which looks fine to me and I haven't changed the run order of
> > autofs in a long, long time.
> > 
> > So, this is looking like NOTABUG to me.
> > 
> > Ian
> 
> Not quite notabug. In addition to the earlier problem, autofs starts in
> runlevel 2 while ypbind starts in runlevel 3:
> 
> [dmack@citrine(Linux)]:/etc/init.d
> > chkconfig --list autofs
> autofs          0:off   1:off   2:on    3:on    4:on    5:on    6:off
> [dmack@citrine(Linux)]:/etc/init.d
> > chkconfig --list ypbind
> ypbind          0:off   1:off   2:off   3:on    4:on    5:on    6:off

Again, this hasn't changed for a long long time.
And in Rawhide the autofs init script has:

# chkconfig: 345 28 72

which I think already does what you're requesting above?
Comment 7 Ian Kent 2009-01-06 00:25:22 EST
*** Bug 476934 has been marked as a duplicate of this bug. ***
Comment 8 Ian Dall 2009-01-08 01:16:55 EST
This really is a bug! The chkconfig line above is correct, but seemingly not interpreted correctly(!):


[root@paprika dalli]# chkconfig autofs off
[root@paprika dalli]# ls /etc/rc.d/rc?.d/*autofs
/etc/rc.d/rc0.d/K72autofs  /etc/rc.d/rc3.d/K72autofs  /etc/rc.d/rc6.d/K72autofs
/etc/rc.d/rc1.d/K72autofs  /etc/rc.d/rc4.d/K72autofs
/etc/rc.d/rc2.d/K72autofs  /etc/rc.d/rc5.d/K72autofs
[root@paprika dalli]# chkconfig autofs on
[root@paprika dalli]# ls /etc/rc.d/rc?.d/*autofs
/etc/rc.d/rc0.d/K72autofs  /etc/rc.d/rc3.d/S28autofs  /etc/rc.d/rc6.d/K72autofs
/etc/rc.d/rc1.d/K72autofs  /etc/rc.d/rc4.d/S28autofs
/etc/rc.d/rc2.d/S28autofs  /etc/rc.d/rc5.d/S28autofs
[root@paprika dalli]# 

The net effect is that one can boot straight into runlevel 3 or 4 OK, but if you boot into runlevel 2, then telinit to runlevel 3 or 4, the autofs doesn't work because it was started before ypbind.
Comment 9 Bill Nottingham 2009-01-08 09:26:17 EST
Does the autofs or ypbind script have LSB-style deps? If so, It's likely being rearranged based on those.
Comment 10 Ian Kent 2009-01-08 09:39:11 EST
(In reply to comment #9)
> Does the autofs or ypbind script have LSB-style deps? If so, It's likely being
> rearranged based on those.

autofs doesn't.
Should I add them?
Comment 11 Bill Nottingham 2009-01-08 09:43:07 EST
Not necessarily. I assume that means ypbind does?
Comment 12 Ian Kent 2009-01-08 09:55:50 EST
(In reply to comment #11)
> Not necessarily. I assume that means ypbind does?

I don't see one in F-9 but in devel:

### BEGIN INIT INFO
# Provides: $ypbind
# Required-Start: $network $syslog
# Required-Stop: $network $syslog

# Default-Start:
# Default-Stop: 0 1 2 3 4 5 6

Is this OK?

# Short-Description: start|stop|restart|condrestart|try-restart|reload|force-reload|status NIS client
# Description: This is a daemon which runs on NIS/YP clients and binds them to a NIS domain
### END INIT INFO

This must have been added fairly recently then.
Comment 13 Bill Nottingham 2009-01-08 10:08:04 EST
(In reply to comment #12)
> (In reply to comment #11)
> > Not necessarily. I assume that means ypbind does?
> 
> I don't see one in F-9 but in devel:
> 
> ### BEGIN INIT INFO
> # Provides: $ypbind
> # Required-Start: $network $syslog
> # Required-Stop: $network $syslog
> 
> # Default-Start:
> # Default-Stop: 0 1 2 3 4 5 6
> 
> Is this OK?

If whatever provides the network or syslog service ends up starting at 27, that means ypbind will be 'pushed' to 28.

A first step to test the fix might be adding LSB deps to autofs with 'Required-Start: ypbind'.
Comment 14 Ian Dall 2009-01-08 16:24:20 EST
Mixing old style chkconfig with LSB style dependencies seems a likely source of bugs, but I don't think it explains how autofs gets enabled at level 2, since nothing else seems to have been told to Require-Start it. I'm suspecting that for some reason chkconfig is ignoring the chkconfig line and using defaults.
Comment 15 Ian Kent 2009-01-08 22:00:55 EST
(In reply to comment #13)
> 
> If whatever provides the network or syslog service ends up starting at 27, that
> means ypbind will be 'pushed' to 28.
> 
> A first step to test the fix might be adding LSB deps to autofs with
> 'Required-Start: ypbind'.

We could but NIS is just one (fairly common) map source.
ypbind being not installed or failing to start or not starting
before autofs might not matter. So it's not a hard dependency
and I'm not sure a "Should-Start:" would have the desired effect.

Anyone know what a "Should-Start:" would do in this case?
Comment 16 Ian Kent 2009-01-08 22:10:30 EST
(In reply to comment #14)
> Mixing old style chkconfig with LSB style dependencies seems a likely source of
> bugs, but I don't think it explains how autofs gets enabled at level 2, since
> nothing else seems to have been told to Require-Start it. I'm suspecting that
> for some reason chkconfig is ignoring the chkconfig line and using defaults.

Yes, that is odd.

I thought the default for chkconfig was start in 345 and stop in
other run levels but the man page is not specific on this point.
It says that, for an add operation, the on and off actions affect
only run levels 2345 but doesn't specify whether that is start or
stop. In any case, as you say, the line in the init script does
specify start in 345 only.
Comment 17 Bill Nottingham 2009-01-09 10:36:42 EST
(In reply to comment #16)
> (In reply to comment #14)
> > Mixing old style chkconfig with LSB style dependencies seems a likely source of
> > bugs, but I don't think it explains how autofs gets enabled at level 2, since
> > nothing else seems to have been told to Require-Start it. I'm suspecting that
> > for some reason chkconfig is ignoring the chkconfig line and using defaults.
> 
> Yes, that is odd.
> 
> I thought the default for chkconfig was start in 345 and stop in
> other run levels but the man page is not specific on this point.
> It says that, for an add operation, the on and off actions affect
> only run levels 2345 but doesn't specify whether that is start or
> stop. In any case, as you say, the line in the init script does
> specify start in 345 only.

The levels in the init script are for what's set up by default when you run --add. on/off do 2/3/4/5.
Comment 18 Fedora Admin XMLRPC Client 2009-02-24 11:15:35 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 19 Ian Kent 2009-03-12 22:59:20 EDT
*** Bug 488774 has been marked as a duplicate of this bug. ***
Comment 20 John Hein 2009-04-08 14:26:06 EDT
I added the fix in 488774 locally and ran chkconfig ypbind off / on to work around the problem with success.  Fedora 10.
Comment 21 Ian Kent 2009-04-08 22:33:24 EDT
(In reply to comment #20)
> I added the fix in 488774 locally and ran chkconfig ypbind off / on to work
> around the problem with success.  Fedora 10.  

I have had something similar in Rawhide for a while now.
Let me add this to the F-10 package and push a build to test and
we'll see if that also resolves the issue.
Comment 22 Dr J Austin 2009-04-11 06:36:16 EDT
Fully updated F10 x86_64
Something has been updated in last few days
This bug has just shown itself on my machines

I have had to change the S28autofs link to S29autofs to avoid
autofs starting before ypbind when booting thus losing home directories etc
Working listing
lrwxrwxrwx 1 root root 16 2009-04-08 15:22 S28vmware -> ../init.d/vmware
lrwxrwxrwx 1 root root 16 2009-04-08 15:22 S28ypbind -> ../init.d/ypbind
lrwxrwxrwx 1 root root 16 2008-12-29 09:47 S29autofs -> ../init.d/autofs

Several things have changed recently including
update of VMware from 6.5.1 to 6.5.2

John
Comment 23 Dr J Austin 2009-04-11 07:44:44 EDT
Updated a different machine
Introduced into F10 by latest ypbind update ?

Before update
lrwxrwxrwx 1 root root 15 2009-03-29 13:43 S26pcscd -> ../init.d/pcscd
lrwxrwxrwx 1 root root 19 2009-01-27 11:16 S26udev-post -> ../init.d/udev-post
lrwxrwxrwx 1 root root 16 2009-01-27 11:27 S27ypbind -> ../init.d/ypbind
lrwxrwxrwx 1 root root 16 2009-01-27 12:54 S28autofs -> ../init.d/autofs
lrwxrwxrwx 1 root root 14 2009-01-27 11:18 S55sshd -> ../init.d/sshd
After update of ypbind
lrwxrwxrwx 1 root root 19 2009-01-27 11:16 S26udev-post -> ../init.d/udev-post
lrwxrwxrwx 1 root root 16 2009-01-27 12:54 S28autofs -> ../init.d/autofs
lrwxrwxrwx 1 root root 16 2009-04-11 11:53 S28ypbind -> ../init.d/ypbind
lrwxrwxrwx 1 root root 14 2009-01-27 11:18 S55sshd -> ../init.d/sshd


ypbind.x86_64 3:1.20.4-10.fc10

John
Comment 24 Ian Kent 2009-04-11 08:21:47 EDT
(In reply to comment #23)
> Updated a different machine
> Introduced into F10 by latest ypbind update ?

Judging by discussions elsewhere I believe it's inappropriate
to add LSB sections to init scripts in what should be a stable
distribution. This whole issue of adding LSB sections should be
worked out in Rawhide and perhaps F-11 and then, if it is
decided to add this to F-10, it needs to be co-ordinated.
So I'm not going to add this to the autofs init scripts in F-10.

Ian
Comment 25 John Hein 2009-04-15 13:17:06 EDT
 > --- Comment #24 from Ian Kent <ikent@redhat.com>  2009-04-11 08:21:47 EDT ---
 > 
 > Judging by discussions elsewhere I believe it's inappropriate
 > to add LSB sections to init scripts in what should be a stable
 > distribution.

Closing the barn door now won't help.  ypbind (recently updated in f10) has it and that's what is causing the reordering and these new "me too" reports.
Comment 26 Ian Kent 2009-04-16 00:33:16 EDT
(In reply to comment #25)
>  > --- Comment #24 from Ian Kent <ikent@redhat.com>  2009-04-11 08:21:47 EDT
> ---
>  > 
>  > Judging by discussions elsewhere I believe it's inappropriate
>  > to add LSB sections to init scripts in what should be a stable
>  > distribution.
> 
> Closing the barn door now won't help.  ypbind (recently updated in f10) has it
> and that's what is causing the reordering and these new "me too" reports.  

Oh right ... so the reasoning is that, since someone else made
a bad decision, I should immediately follow suit.

Enough sarcasm, the fact is that the LSB stuff I added didn't
work the way I expected and I've submitted changes to Rawhide
and F-11 (today) to try and fix that. Also, this may not be
all that is needed and I'm still not sure yet what the final
LSB header will be. OTOH, what I have now should resolve this
problem, so lets give it a little settling time in F-11 and
Rawhide before going ahead and adding it to F-10.
Comment 27 Ian Dall 2009-04-16 04:49:38 EDT
After a yum update (F10) it is back for me. It strikes me that this is a common configuration for an enterprise type environment and it is a bit of a show stopper. I think I'll just put "service autofs restart" in /etc/rc.local if this is going to stay unfixed indefinitely!
Comment 28 Ian Kent 2009-04-16 09:43:44 EDT
(In reply to comment #27)
> After a yum update (F10) it is back for me. It strikes me that this is a common
> configuration for an enterprise type environment and it is a bit of a show
> stopper. I think I'll just put "service autofs restart" in /etc/rc.local if
> this is going to stay unfixed indefinitely!  

Didn't you read comment #26?
Give it a few days or a little more, I've only just now fixed
Rawhide and F-11.
Comment 29 Ian Kent 2009-05-04 03:14:15 EDT
I've had a go at adding an LSB block to the autofs init script
in F-10.

Can some of you give the build at
http://kojipkgs.fedoraproject.org/packages/autofs/5.0.3/43
a try please.
Comment 30 John Hein 2009-06-03 12:32:05 EDT
Yes, the new init.d/autofs in the package from comment #29 (which is more or less the same as the patch in 488774) fixes the ordering issue for me on F10.
Comment 31 Bug Zapper 2009-06-09 06:09:22 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 32 Russell Harrison 2009-06-25 12:49:25 EDT
I've been seeing the same issue on F10 for a while now and when I checked the init scripts I saw that ypbind should have a start order of 27 as described above.  When I checked /etc/rc5.d/ I noticed that it was still configured with a start order of 28.

Simply running "chkconfig ypbind resetpriorities" seems to have fixed that issue and after a reboot everything came up as expected.  Is that something that should be run in %post for upgrades of the ypbind rpms?
Comment 33 Bill Nottingham 2009-06-25 13:07:09 EDT
... maybe? Ideally, it would be handled automatically. But I wonder if making --add do a silent --resetpriorities would make things worse.
Comment 34 Bug Zapper 2010-04-27 08:28:43 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  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 WONTFIX if it remains open with a Fedora 
'version' of '11'.

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 prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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
Comment 35 Bug Zapper 2010-06-28 06:54:35 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.

Thank you for reporting this bug and we are sorry it could not be fixed.

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