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.
Got the advice to report this bug here from Centos: http://bugs.centos.org/view.php?id=4293
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.
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?
for me it seems that this bug is not fixed in rhel6, could not find anything.
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
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)
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.
*** Bug 587524 has been marked as a duplicate of this bug. ***
Sorry for my bad english, but I understood that you are not sure if this is fixed.