Bug 533491
| Summary: | Confusing slapd init script error message | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Daniel Qarras <dqarras> | ||||
| Component: | openldap | Assignee: | Jan Zeleny <jzeleny> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 12 | CC: | jzeleny, tcallawa | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | 2.4.19-1.fc12 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-12-10 04:25:19 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: | |||||||
| Attachments: |
|
||||||
|
Description
Daniel Qarras
2009-11-06 21:21:25 UTC
Reassigning to openldap component. I don't think this is the best option here. We should rather find out why there is pid file present if slapd isn't started. Could you give me some info regarding this? As shown by the example, this happens only if the users (erroneously) start the slapd server twice in a row. Perhaps this just a luser error and as such there is no need for a change in the script. Created attachment 368348 [details]
Patch adding detection if slapd is started
I think modification is in order here - when slapd is started, init script should detect it and don't try to start it again. I made a simple patch doing this. If it is acceptable solution, I'll commit the changes to CVS.
This seems to be a bit problematic: root@localhost:~# rm -rf /etc/openldap/slapd.d/ root@localhost:~# /etc/init.d/slapd stop slapd (pid 2772) is running... root@localhost:~# /etc/init.d/slapd start find: `directory/': No such file or directory Starting slapd: ln: creating hard link `/var/run/slapd.pid': File exists root@localhost:~# killall slapd root@localhost:~# /etc/init.d/slapd stop Stopping slapd: [FAILED] root@localhost:~# /etc/init.d/slapd status slapd is stopped root@localhost:~# /etc/init.d/slapd start slapd is stopped root@localhost:~# Ok, first thing - I forgot to add > /dev/null to status calls, that's why "slapd is running" line is there. Second - I don't get how it is possible that the ln error message persists. Could you run service slapd status and echo return code before starting slapd? And the last thing - when killing slapd manually, service slapd stop isn't going to work and service slapd start as well. service slapd status should inform you about that by means of its return code, try to check it. If it detects incorrectly stopped slapd, it is up to system admin to fix the problem first and start slapd afterwards. This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Please note that this was the error I was most worried: root@localhost:~# /etc/init.d/slapd stop slapd (pid 2772) is running... That's not an error, it's an output of status function, called to figure out if slapd is running. That output is now suppressed. openldap-2.4.19-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/openldap-2.4.19-1.fc12 openldap-2.4.19-1.fc12 has been pushed to the Fedora 12 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 openldap'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-11725 openldap-2.4.19-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. |