Bug 806424 - ipactl.service fails on boot - but not if manually started
ipactl.service fails on boot - but not if manually started
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: freeipa (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Rob Crittenden
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 824495
  Show dependency treegraph
 
Reported: 2012-03-23 13:24 EDT by Ian Chapman
Modified: 2013-11-22 07:08 EST (History)
5 users (show)

See Also:
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 07:08:48 EST
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 Ian Chapman 2012-03-23 13:24:06 EDT
Description of problem:

The ipactl.service fails on boot, but not if it is subsequently restarted manually on boot up



Version-Release number of selected component (if applicable):
freeipa-server-2.1.4-5.fc16.x86_64

How reproducible:
Installed freeipa as per the instructions on the Fedora web site and ipactl.service always fails on boot up but not if restarted manually

Steps to Reproduce:
1.
2.
3.
  
Actual results:

It should start up

Expected results:

It does not start

Additional info:

I've worked around this by doing a systemctl enable dirsrv.target and now the ipactl.service does start on boot. What "seems" to happen is that ipactl starts the 389 directory server but as far as systemd is concerned that target (dirsrv.target) isn't wanted so it immediately shuts it down. Then the subsequent services that ipactl tries to start fail because they can't contact the 389 directory service. By explicitly enabling the dirsrv.target - it does not get shutdown by systemd.

With systemd supposedly being all singing - all dancing - is ipactl the correct thing to do - or should it be properly converted so that systemd itself starts the required services? At the very least it would appear the ipactl.service may need a dependency on dirsrv.target adding.
Comment 1 Ian Chapman 2012-03-23 13:42:02 EDT
Of course where I've written ipactl.service, I do of course mean ipa.service
Comment 2 Alexander Bokovoy 2012-03-23 14:53:08 EDT
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?
Comment 3 Ian Chapman 2012-03-23 22:50:27 EDT
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]
Comment 4 Ian Chapman 2012-03-25 05:21:41 EDT
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.
Comment 5 Dmitri Pal 2012-04-23 15:15:47 EDT
Any update?
Comment 6 Ian Chapman 2012-04-24 09:28:36 EDT
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.
Comment 7 Ian Chapman 2012-04-24 11:19:14 EDT
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
Comment 8 Rob Crittenden 2012-05-22 10:42:47 EDT
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/2774
Comment 9 Fedora End Of Life 2013-01-16 19:14:50 EST
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
Comment 10 Rob Crittenden 2013-01-17 09:19:41 EST
Moving to F-18. We've addressed shutdown issues, startup still requires starting dirsrv to get the list of services.
Comment 11 Ian Chapman 2013-04-12 11:06:49 EDT
Were the shutdown issues fixed in F17 or F18?
Comment 12 Rob Crittenden 2013-04-12 11:26:47 EDT
The shutdown issues were addressed in IPA v3.0, so F-18 (see commits 9c388e9b6257c8fd27fb590d9a45e850e4d945b8, 2eb29f42679632f7eed813638cdf33e60c13a249 and f5805379277d0d9a2685aba69db49c95a36a6d1f)
Comment 13 Martin Kosek 2013-11-22 07:08:48 EST
I see we forgot to close this Bugzilla, given that the issues were fixed.

Closing it now.

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