Bug 489200 - ypbind init script returns 1 on success
Summary: ypbind init script returns 1 on success
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: ypbind
Version: 10
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Vitezslav Crhonek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-03-08 15:28 UTC by Daniel Qarras
Modified: 2009-04-20 19:31 UTC (History)
4 users (show)

Fixed In Version: 1.20.4-10.fc10
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-06 20:23:21 UTC


Attachments (Terms of Use)

Description Daniel Qarras 2009-03-08 15:28:45 UTC
Description of problem:
When doing a successful

# service ypbind start

the ypbind init script returns 1 due to following:

...
case "$1" in
  start)
        start
	[ $? -eq 100 ] && stop
        ;;
...
esac

exit $?

Because [ $? -eq 100 ] is not true, $? is set to 1 and thus exit $? will be exit 1. One fix would be to change the check to "[ $? -eq 100 ] && stop || :".

Version-Release number of selected component (if applicable):
ypbind-1.20.4-8.fc10.i386

How reproducible:
Always.

Steps to Reproduce:
1. Configure YP
2. service ypbind start
3. echo $?
  
Actual results:
Return value of 1 from ypbind init script even when the service was successfully started.

Expected results:
Return value of 0 when the service is started successfully.

Additional info:

Comment 1 Fedora Update System 2009-03-11 11:47:03 UTC
ypbind-1.20.4-10.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/ypbind-1.20.4-10.fc10

Comment 2 Fedora Update System 2009-03-11 17:55:22 UTC
ypbind-1.20.4-10.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update ypbind'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2567

Comment 3 Fedora Update System 2009-04-06 20:23:17 UTC
ypbind-1.20.4-10.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 4 JM 2009-04-08 15:40:03 UTC
The new initscript breaks the priority, the old start priority was 27 but with the new script it is 28, that's the same priority "autofs" has and so autofs fails (most of the time) to load the automount maps from NIS (after a reboot) because NIS is not ready when autofs starts, this way autofs can't find the /home/ directories and because of this no one can login...

I checked the new ypbind script and chkconfig is

# chkconfig: - 27 73

so the ypbind script should have the right priority 27 but instead it is 28:

lrwxrwxrwx 1 root root 16 2009-04-08 17:28 /etc/rc3.d/S28ypbind -> ../init.d/ypbind

I tried "chkconfig --del ypbind" and then "chkconfig --add ypbind; chkconfig ypbind on" but the result was the same (priority 28 instead of 27):

lrwxrwxrwx 1 root root 16 2009-04-08 17:31 /etc/rc3.d/S28ypbind -> ../init.d/ypbind

So I checked what you changed in the new ypbind script and I saw that /etc/init.d/ypbind has now this on top:

### BEGIN INIT INFO
# Provides: $ypbind
# Required-Start: $network $syslog
# Required-Stop: $network $syslog
# Default-Start:
# Default-Stop: 0 1 2 3 4 5 6
# 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

I did a "chkconfig --del ypbind" and removed this part (the INIT INFO stuff) from the script and then I tried again "chkconfig --add ypbind; chkconfig ypbind on" and now the priority is 27:

lrwxrwxrwx 1 root root 16 2009-04-08 17:35 /etc/rc3.d/S27ypbind -> ../init.d/ypbind

I don't know why the INIT INFO stuff breaks the priority but I checked it on 5 different systems and all have with the new ypbind RPM (ypbind-1.20.4-10.fc10) the same problem, I removed on all systems the INIT INFO stuff from the script and now it works.

Comment 5 JM 2009-04-08 15:46:12 UTC
The problematic part is the $ in

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

I changed (removed the $ sign) it to:

### BEGIN INIT INFO
# Provides: ypbind
# Required-Start: network syslog
# Required-Stop: network syslog
# Default-Start:
# Default-Stop: 0 1 2 3 4 5 6
# 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

and now 27 is again the priority after an "chkconfig --add ypbind; chkconfig
ypbind on", it looks like "chkconfig" doesn't like the $ sign in the comments.

Comment 6 Jack Perdue 2009-04-20 19:31:37 UTC
JM, I ran into a similar problem.  After digging through the source, I found, like you, that it is due to ypbind's init now using the Required-Start/Required-Stop bits.

I'm willing to wager you have NetworkManager installed.

If you look in NetworkManager's init script, it has a "Provides: $network".  
The code sees that and since ypbind requires $network to start, it adjusts the 27 
to come just after NetworkManager, which is also 27.  That puts ypbind at 28, 
which of course breaks stuff (autofs).  The proper fix seems to be remove 
NetworkManager, which probably shouldn't be needed/installed anyway in a NIS
environment.  i.e.

yum remove NetworkManager
chkconfig ypbind off
chkconfig ypbind on

Then you'll end up with S27ypbind vs. S28ypbind in rc3.d.

Fortunately you can do that in FC10 (you can't in FC9 and RHEL5 due to evolution's dependencies on NetworkManager-glib).

So this new "problem" isn't really a problem unless you use NetworkManager AND NIS, which is probably not a supported combination.  Just FYI.


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