Bug 806424
| Summary: | ipactl.service fails on boot - but not if manually started | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ian Chapman <packages> | |
| Component: | freeipa | Assignee: | Rob Crittenden <rcritten> | |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 18 | CC: | abokovoy, dpal, mkosek, rcritten, ssorce | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | freeipa-3.1.5-1.fc18 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 824495 (view as bug list) | Environment: | ||
| Last Closed: | 2013-11-22 12:08:48 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: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 824495 | |||
|
Description
Ian Chapman
2012-03-23 17:24:06 UTC
Of course where I've written ipactl.service, I do of course mean ipa.service Ian, if you would add the dependency on dirsrv.target, is it allowing the start after boot for ipa.service? Could you please check it? I've just done the following (to try and return back to the previous state): systemctl disable dirsrv.target and now after rebooting, ipa.service still starts up correctly, so I'm not sure what systemd is doing differently now on boot up versus before when it didn't work. I've dug out the boot.log from my backups (when it didn't start on boot) and you can see the following: Started NFS Server [ESC[1;32m OK ESC[0m] Starting Secure NFS Server... Starting 389 Directory Server PKI-IPA.... Starting 389 Directory Server HOMENET-LAN.... named[1678]: Starting named: [ OK ] Started LSB: start|stop|status|restart|try-restart|reload|force-reload DNS server [ESC[1;32m OK ESC[0m] Starting NFS file locking service.... Started 389 Directory Server PKI-IPA. [ESC[1;32m OK ESC[0m] Started 389 Directory Server HOMENET-LAN. [ESC[1;32m OK ESC[0m] Started Secure NFS Server [ESC[1;32m OK ESC[0m] Started NFS file locking service. [ESC[1;32m OK ESC[0m] Started MySQL database server [ESC[1;32m OK ESC[0m] Stopping 389 Directory Server PKI-IPA.... Stopping 389 Directory Server HOMENET-LAN.... Stopped 389 Directory Server HOMENET-LAN. [ESC[1;32m OK ESC[0m] Stopped 389 Directory Server PKI-IPA. [ESC[1;32m OK ESC[0m] Failed to start Identity, Policy, Audit [ESC[1;31mFAILEDESC[0m] See 'systemctl status ipa.service' for details. I'm happy to add dirsrv.target as a dependency but somehow I need to return to the previous state so that it fails on boot, to check whether adding that dependency works. This is what boot.log shows now (even with dirsrv.target disabled) Started NFS Server [ESC[1;32m OK ESC[0m] Starting Secure NFS Server... Started Secure NFS Server [ESC[1;32m OK ESC[0m] Started Samba SMB Daemon [ESC[1;32m OK ESC[0m] Starting 389 Directory Server PKI-IPA.... Starting 389 Directory Server HOMENET-LAN.... named[1648]: Starting named: [ OK ] Started LSB: start|stop|status|restart|try-restart|reload|force-reload DNS server [ESC[1;32m OK ESC[0m] Starting NFS file locking service.... Started 389 Directory Server HOMENET-LAN. [ESC[1;32m OK ESC[0m] Started 389 Directory Server PKI-IPA. [ESC[1;32m OK ESC[0m] Started NFS file locking service. [ESC[1;32m OK ESC[0m] Well I just rebooted the box again today - changing nothing to do with any of the services or FreeIPA and it's failed to start again on boot (dirsrv.target is still disabled from the other day). It seems there is some randomness involved too - still smacks of a missing service dependency. I'll try and do some more concrete testing. Any update? Yes, ipa.service has consistently failed to start on boot for weeks now (actually ever since I last left dirsrv.target disabled). I've just done: systemctl enable dirsrv.target then rebooted the system (which fails to shutdown cleanly also) but if i hold down ctrl-alt-del then it eventually does. And on boot up, ipa.service correctly starts! I wish there was a decent away to diagnose systemd problems - it totally sucks for that. I've also done the following: cp -a /lib/systemd/system/ipa.service /etc/systemd/system/ edited /etc/systemd/system/ipa.service and changed the following line Requires=syslog.target network.target to Requires=syslog.target network.target dirsrv.target Upstream ticket: https://fedorahosted.org/freeipa/ticket/2774 This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 '16'. 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 16'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 16 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 to click on "Clone This Bug" and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Moving to F-18. We've addressed shutdown issues, startup still requires starting dirsrv to get the list of services. Were the shutdown issues fixed in F17 or F18? The shutdown issues were addressed in IPA v3.0, so F-18 (see commits 9c388e9b6257c8fd27fb590d9a45e850e4d945b8, 2eb29f42679632f7eed813638cdf33e60c13a249 and f5805379277d0d9a2685aba69db49c95a36a6d1f) I see we forgot to close this Bugzilla, given that the issues were fixed. Closing it now. |