Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 587210

Summary: /etc/init.d/ldap is not LSB compliant
Product: Red Hat Enterprise Linux 5 Reporter: Achim Stumpf <hakim.news>
Component: openldapAssignee: Jan Zeleny <jzeleny>
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: low Docs Contact:
Priority: low    
Version: 5.4CC: jplans, ralph
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-04-29 13:15:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Achim Stumpf 2010-04-29 11:44:02 UTC
Description of problem:

For a very urgent cleanup of a heartbeat v1 cluster I recognized, that this init script is not LSB compliant. See

http://www.linux-ha.org/LSBResourceAgent [^]
http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html [^]

From my tests for LSB compliance I got the following result:

[root@cube3service1 ha.d]# /etc/init.d/ldap start
Checking configuration files for slapd: config file testing succeeded
                                                           [ OK ]
Starting slapd: [ OK ]
Starting slurpd: [ OK ]
[root@cube3service1 ha.d]# echo $?
0
[root@cube3service1 ha.d]# /etc/init.d/ldap status
slapd (pid 31953) is running...
slurpd (pid 31960) is running...
[root@cube3service1 ha.d]# echo $?
0


[root@cube3service1 ha.d]# /etc/init.d/ldap start
Checking configuration files for slapd: config file testing succeeded
                                                           [ OK ]
Starting slapd: [FAILED]

[root@cube3service1 ha.d]# echo $?
1
#
# should return 0 and services should not start a second time
#

[root@cube3service1 ha.d]# /etc/init.d/ldap stop
Stopping slapd: [ OK ]
Stopping slurpd: [ OK ]
[root@cube3service1 ha.d]# echo $?
0
[root@cube3service1 ha.d]# /etc/init.d/ldap status
slapd is stopped
slurpd is stopped
[root@cube3service1 ha.d]# echo $?
3
[root@cube3service1 ha.d]# /etc/init.d/ldap stop
Stopping slapd: [FAILED]
Stopping slurpd: [FAILED]
[root@cube3service1 ha.d]# echo $?
0

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


How reproducible:


Steps to Reproduce:


Actual results:


Expected results:


Additional info:

Here is my patch to fix this:

$ svn diff -r 325 ldap
Index: ldap
===================================================================
--- ldap (revision 325)
+++ ldap (working copy)
@@ -199,29 +199,39 @@
     return $RETVAL
 }
 
+function status_ldap() {
+ status ${slapd}
+ RETVAL=$?
+ if grep -q "^replogfile" /etc/openldap/slapd.conf ; then
+ status ${slurpd}
+ RET=$?
+ if [ $RET -ne 0 ] ; then
+ RETVAL=$RET;
+ fi
+ fi
+ return $RETVAL
+}
+
 # See how we were called.
 case "$1" in
     configtest)
     configtest
     ;;
     start)
- start
- RETVAL=$?
+ status_ldap
+ RETVAL=$?
+ if [ $RETVAL -ne 0 ]; then
+ start
+ RETVAL=$?
+ fi
     ;;
     stop)
     stop
     RETVAL=$?
     ;;
     status)
- status ${slapd}
- RETVAL=$?
- if grep -q "^replogfile" /etc/openldap/slapd.conf ; then
- status ${slurpd}
- RET=$?
- if [ $RET -ne 0 ] ; then
- RETVAL=$RET;
- fi
- fi
+ status_ldap
+ RETVAL=$?
     ;;
     restart)
     stop

This is a diff to the original version as I have got it on Centos 5.4. I know it is quick and dirty, haven't got the time to fix it nicely.

Comment 1 Achim Stumpf 2010-04-29 11:45:08 UTC
Got the advice to report this bug here from Centos:

http://bugs.centos.org/view.php?id=4293

Comment 2 Jan Zeleny 2010-04-29 13:15:44 UTC
This issue won't be addressed in RHEL5. The reason is obvious - users might already use their own scripts which depend on current behavior. Feel free to test latest Fedora or RHEL6 beta1, the issue should be already fixed there.

Comment 3 Achim Stumpf 2010-04-30 06:00:56 UTC
Please could you move this to the rhel6 queue with status new. I don't have the permission to do this.

Or are you expecting now that I open a new Bug report in the rhel6 queue?

Comment 4 Achim Stumpf 2010-04-30 06:10:06 UTC
for me it seems that this bug is not fixed in rhel6, could not find anything.

Comment 5 Jan Zeleny 2010-04-30 06:34:15 UTC
If you tested openldap in RHEL-6 beta and you found that it doesn't follow Fedora guidelines (they are based on LSB), please file a new bug with description what part doesn't follow guidelines. Thanks

Comment 6 Achim Stumpf 2010-04-30 06:54:13 UTC
I don't have the time to install rhel6 beta. My customer is not paying anymore. And I have opened a bugreport on centos, they gave me the advice to report it on rhel, now you guys tell me that ... This is a lot of time to report a bug. In real open source distributions this is much simpler and not so time costing... ;o)

Comment 7 Jan Zeleny 2010-04-30 07:09:29 UTC
My point for the installing and testing was that the bug was already fixed, as I told you in comment 2. So you've opened unnecessary bug.

Comment 8 Jan Zeleny 2010-04-30 07:18:36 UTC
*** Bug 587524 has been marked as a duplicate of this bug. ***

Comment 9 Achim Stumpf 2010-04-30 07:21:13 UTC
Sorry for my bad english, but I understood that you are not sure if this is fixed.