Bug 587210 - /etc/init.d/ldap is not LSB compliant
/etc/init.d/ldap is not LSB compliant
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openldap (Show other bugs)
5.4
All Linux
low Severity low
: rc
: ---
Assigned To: Jan Zeleny
BaseOS QE Security Team
:
: 587524 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-29 07:44 EDT by Achim Stumpf
Modified: 2010-04-30 03:21 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-04-29 09:15:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Achim Stumpf 2010-04-29 07:44:02 EDT
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 07:45:08 EDT
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 09:15:44 EDT
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 02:00:56 EDT
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 02:10:06 EDT
for me it seems that this bug is not fixed in rhel6, could not find anything.
Comment 5 Jan Zeleny 2010-04-30 02:34:15 EDT
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 02:54:13 EDT
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 03:09:29 EDT
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 03:18:36 EDT
*** Bug 587524 has been marked as a duplicate of this bug. ***
Comment 9 Achim Stumpf 2010-04-30 03:21:13 EDT
Sorry for my bad english, but I understood that you are not sure if this is fixed.

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