#1315 pki-tomcatd fails to start on system boot
Closed: Fixed None Opened 5 years ago by bja.

Testing with dogtag 10.0.2.1, it does not appear that the dogtag service starts on boot.

Following an install:

[root@cfgdev-intca01 ~]# systemctl list-units | grep pki
pki-tomcatd@pki-tomcat.service loaded active running PKI Tomcat Server pki-tomcat
system-pki\x2dtomcatd.slice loaded active active system-pki\x2dtomcatd.slice
pki-tomcatd.target loaded active active PKI Tomcat Server

After rebooting the OS:

[root@cfgdev-intca01 ~]# systemctl list-units | grep pki
[cfgdev-intca01.iam.redhat.com] [01:29:15 PM]

pkispawn should configure the system to start the pki-tomcat service at boot.

Red Hat Enterprise Linux Server release 7.1 (Maipo)
pki-ca-10.2.1-1.el7.noarch
pki-base-10.2.1-1.el7.noarch
pki-server-10.2.1-1.el7.noarch
dogtag-pki-server-theme-10.2.1-1.el7.noarch
pki-tools-10.2.1-1.el7.x86_64


Per CS/DS meeting of 2015/03/23: 10.2.3

This patch replaces 20150409-pki-tomcatd-fails-to-start-on-boot.patch.
20150410-pki-tomcatd-fails-to-start-on-boot.patch

Note that the DS is not automatically configured to start at boot time:
https://fedorahosted.org/389/ticket/47616

It has to be enabled manually:
http://www.port389.org/docs/389ds/howto/howto-systemd.html#how-do-i-make-it-start-at-boot-time

Currently there is a bug with the manual configuration:
https://fedorahosted.org/389/ticket/48147

This will block Dogtag startup at boot time if the DS is running on the same machine.

Replying to [comment:5 edewata]:

Note that the DS is not automatically configured to start at boot time:
https://fedorahosted.org/389/ticket/47616

It has to be enabled manually:
http://www.port389.org/docs/389ds/howto/howto-systemd.html#how-do-i-make-it-start-at-boot-time

Currently there is a bug with the manual configuration:
https://fedorahosted.org/389/ticket/48147

This will block Dogtag startup at boot time if the DS is running on the same machine.

Please note that the attached patch appears to address this issue for Dogtag with the changes to the following two files:

  • pki/base/server/share/lib/systemd/system/pki-tomcatd.target
  • pki/base/server/share/lib/systemd/system/pki-tomcatd@.service

By adding the lines "Wants=dirsrv.target" and "After=...dirsrv.target", testing revealed, that if 389 is locally present on the system, it will be started up on boot whenever Dogtag has been configured to start on boot.

It should also be noted that since "Wants" was used rather than "Requires", testing also revealed that it would not stop Dogtag from starting up if 389 did not exist locally on the machine (i. e. - Dogtag relies upon using a 389 server reachable on the network rather than locally).

The one small problem with the proposed solution is if a deployment contained a machine which required having both 389 and Dogtag on it, but Dogtag actually utilized a network reachable 389 rather that the local 389; the local 389 would still be started upon boot due to this logic. It may be possible for a deployment to address this scenario by using systemd.preset logic.

Checked into master:

  • 18b24a990ff9b97cf58aa630af0084975fe4c130

Metadata Update from @bja:
- Issue assigned to mharmsen
- Issue set to the milestone: 10.2.3

4 years ago

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/1877

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Login to comment on this ticket.

Metadata