Bug 846787
| Summary: | multiple bugs in start-dirsrv, stop-dirsrv, restart-dirsrv scripts - with suggested fixes | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | John Ellson <john.ellson> | ||||||||
| Component: | 389-ds-base | Assignee: | mreynolds | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 17 | CC: | edewata, mreynolds, nhosoi, nkinder, rmeggins | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2013-08-01 05:19:23 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 603082 [details]
replacement for /sbin/stop-dirsrv
Created attachment 603083 [details]
replacement for /sbin/restart-dirsrv
Note: better to use systemctl with F17 - http://port389.org/wiki/Howto:systemd I thought I'd read someplace that you couldn't start TLS-enabled servers like that... but I must have misread ...
Much better! Thanks
( I did:
# systemctl enable dirsrv.target
# reboot
and every came up running.)
So, would it be better to remove those scripts altogether (and from the documentation) so that we always use systemctl ?
(In reply to comment #4) > I thought I'd read someplace that you couldn't start TLS-enabled servers > like that... but I must have misread ... > > Much better! Thanks > > ( I did: > # systemctl enable dirsrv.target > # reboot > and every came up running.) > > So, would it be better to remove those scripts altogether (and from the > documentation) so that we always use systemctl ? Yes, or just make the scripts wrappers around systemctl. (In reply to comment #5) > (In reply to comment #4) > > I thought I'd read someplace that you couldn't start TLS-enabled servers > > like that... but I must have misread ... > > > > Much better! Thanks > > > > ( I did: > > # systemctl enable dirsrv.target > > # reboot > > and every came up running.) > > > > So, would it be better to remove those scripts altogether (and from the > > documentation) so that we always use systemctl ? > > Yes, or just make the scripts wrappers around systemctl. It's quite handy for debugging (e.g., to run callgrind & valgrind, quickly :). But it's okay for me not to "install" the file as long as we keep it in the source tree... Upstream ticket: https://fedorahosted.org/389/ticket/433 Comments about the reported problems... [1] 10 minute wait for the PIDFILE - this is actually necessary because if you have verbose error logging enabled, it can take several minutes until this file is written. [2] The file ".startpid" is used/necessary [3] "-w" - this is used by the server internally The current fix approach will be to ignore "dirsrv-admin" when running the start/stop/restart scripts. Also, setup-ds.pl/setup-ds-admin.pl will not allow the use of DS instances named "admin". This prevents the admin server identifier, in /etc/sysconfig/, from being overwritten by a DS instance named "admin". Fix committed: 6ddfaa021a9db243ffe89527bf6f70bbd08435cc Slight amendment to original patch: 54112e4c4867bf7b1d9dcf928155dc4160304464 This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |
Created attachment 603081 [details] replacement for /sbin/start-dirsrv Description of problem: The scripts: /sbin/start-dirsrv, /sbin/stop-dirsrv, /sbin/restart-dirsrv are broken. - contains reasonable 10sec waits for pid, followed by broken 10 minute waits for PIDFILE - 10sec wait doesn't continue if it succeeds in lt 10sec - start-dirsrv creates *.startpid file which never gets used - start-dirsrv removes its newly created PIDFILE - tries to start the admin server with ns-dlapd ( "for i in $initconfig_dir/dirsrv-*; do" matches "/etc/sysconfig/dirsrv-admin" ) - tries to use non-existant (or non-documented) -w option on ns-dlapd Version-Release number of selected component (if applicable): 389-ds-base-1.2.11.5-1.fc17.x86_64 How reproducible: 100% Steps to Reproduce: 1. start-dirsrv 2. restart-dirsrv 3. stop-dirsrv Actual results: # start-dirsrv Starting instance "admin" /sbin/start-dirsrv: line 63: ./ns-slapd: No such file or directory Starting instance "lweb1-vhost4" There is an ns-slapd running: 2820 # restart-dirsrv Restarting instance "admin" No ns-slapd PID file found. Server is probably not running /usr/sbin/start-dirsrv: line 63: ./ns-slapd: No such file or directory Restarting instance "lweb1-vhost4" # stop-dirsrv Stopping instance "admin" No ns-slapd PID file found. Server is probably not running Stopping instance "lweb1-vhost4" # Expected results: # start-dirsrv Starting instance "lweb1-vhost4" # restart-dirsrv Restarting instance "lweb1-vhost4" # stop-dirsrv Stopping instance "lweb1-vhost4" # # start-dirsrv Starting instance "lweb1-vhost4" # start-dirsrv Starting instance "lweb1-vhost4" There is an ns-slapd process already running: 3164 # # stop-dirsrv Stopping instance "lweb1-vhost4" # stop-dirsrv Stopping instance "lweb1-vhost4" No ns-slapd PID file found. Server is probably not running # Additional info: Poroposed replacement scripts attached below.