#8907 CentOS 8: pki-tomcatd@pki-tomcat.service fails to start after upgrade
Closed: invalid 2 years ago by abbra. Opened 2 years ago by askipin.

As admin, I updated freeipa packages on Centos 8 server from
4.9.2-3.module_el8.5.0+750+c59b186b to 4.9.2-4.module_el8.4.0+846+96522ed7
and executed ipa-server-upgrade

Issue

ipa-server-upgrade did not finish due to

Unexpected error - see /var/log/ipaupgrade.log for details:
CalledProcessError: CalledProcessError(Command ['/bin/systemctl', 'start', 'pki-tomcatd@pki-tomcat.service'] returned non-zero exit status 1: 'Job for pki-tomcatd@pki-tomcat.service failed because a timeout was exceeded.\nSee "systemctl status pki-tomcatd@pki-tomcat.service" and "journalctl -xe" for details.\n')

[root@freeipa01 ~]# systemctl status pki-tomcatd@pki-tomcat.service
● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat
Loaded: loaded (/usr/lib/systemd/system/pki-tomcatd@.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/pki-tomcatd@pki-tomcat.service.d
└─ipa.conf
Active: failed (Result: timeout) since Thu 2021-07-01 07:39:49 MSK; 30min ago
Process: 789921 ExecStartPost=/usr/libexec/ipa/ipa-pki-wait-running (code=killed, signal=TERM)
Process: 789920 ExecStart=/usr/libexec/tomcat/server start (code=exited, status=143)
Process: 789835 ExecStartPre=/usr/bin/pkidaemon start pki-tomcat (code=exited, status=0/SUCCESS)
Process: 789787 ExecStartPre=/usr/sbin/pki-server migrate pki-tomcat (code=exited, status=0/SUCCESS)
Process: 789783 ExecStartPre=/usr/sbin/pki-server upgrade pki-tomcat (code=exited, status=0/SUCCESS)
Main PID: 789920 (code=exited, status=143)

Jul 01 07:39:43 freeipa01.plk32.local ipa-pki-wait-running[789921]: ipa-pki-wait-running: Request failed unexpectedly, 404 Client Error: for url: http://freeipa01.plk32.local:8080/ca/admin/ca/getStatus
Jul 01 07:39:44 freeipa01.plk32.local ipa-pki-wait-running[789921]: ipa-pki-wait-running: Request failed unexpectedly, 404 Client Error: for url: http://freeipa01.plk32.local:8080/ca/admin/ca/getStatus
Jul 01 07:39:45 freeipa01.plk32.local ipa-pki-wait-running[789921]: ipa-pki-wait-running: Request failed unexpectedly, 404 Client Error: for url: http://freeipa01.plk32.local:8080/ca/admin/ca/getStatus
Jul 01 07:39:46 freeipa01.plk32.local ipa-pki-wait-running[789921]: ipa-pki-wait-running: Request failed unexpectedly, 404 Client Error: for url: http://freeipa01.plk32.local:8080/ca/admin/ca/getStatus
Jul 01 07:39:47 freeipa01.plk32.local ipa-pki-wait-running[789921]: ipa-pki-wait-running: Request failed unexpectedly, 404 Client Error: for url: http://freeipa01.plk32.local:8080/ca/admin/ca/getStatus
Jul 01 07:39:48 freeipa01.plk32.local ipa-pki-wait-running[789921]: ipa-pki-wait-running: Request failed unexpectedly, 404 Client Error: for url: http://freeipa01.plk32.local:8080/ca/admin/ca/getStatus
Jul 01 07:39:49 freeipa01.plk32.local ipa-pki-wait-running[789921]: ipa-pki-wait-running: Request failed unexpectedly, 404 Client Error: for url: http://freeipa01.plk32.local:8080/ca/admin/ca/getStatus
Jul 01 07:39:49 freeipa01.plk32.local systemd[1]: pki-tomcatd@pki-tomcat.service: Start-post operation timed out. Stopping.
Jul 01 07:39:49 freeipa01.plk32.local systemd[1]: pki-tomcatd@pki-tomcat.service: Failed with result 'timeout'.
Jul 01 07:39:49 freeipa01.plk32.local systemd[1]: Failed to start PKI Tomcat Server pki-tomcat.

Steps to Reproduce

  1. update 4.9.2-3.module_el8.5.0+750+c59b186b to 4.9.2-4.module_el8.4.0+846+96522ed7
  2. run ipa-server-upgrade

Actual behavior

ipa-server-upgrade failed
ipactl start failed

ipactl can start only with force option, with failed pki-tomcatd service

Expected behavior

ipa-server-upgrade executed successfully
ipactl start normally

Version/Release/Distribution

$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server

package freeipa-server is not installed
package freeipa-client is not installed
ipa-server-4.9.2-4.module_el8.4.0+846+96522ed7.x86_64
ipa-client-4.9.2-4.module_el8.4.0+846+96522ed7.x86_64
389-ds-base-1.4.3.16-16.module_el8.4.0+845+0c39e1b7.x86_64
pki-ca-10.10.5-3.module_el8.4.0+816+beb6e9a3.noarch
krb5-server-1.18.2-8.el8.x86_64

Additional info:

netstat is empty
[root@freeipa01 ~]# netstat -natp | grep 8080
[root@freeipa01 ~]#


Some users have reported that downgrading the 389-ds-base helped.

We have no control over the centOS packages and do not test them.

Some users have reported that downgrading the 389-ds-base helped.

Could you please share command for that?

dnf downgrade 389-ds-base

In particular someone on IRC reported that 389-ds-base-0:1.4.3.16-13 is ok and it failed with 389-ds-base-1.4.3.16-16

dnf downgrade 389-ds-base

It works!

Metadata Update from @askipin:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Metadata Update from @cheimes:
- Issue status updated to: Open (was: Closed)

2 years ago

@vashirov found out this is a bug in CentOS due to unreleased nss version: 389-ds-base 1.4.3.16-16 is built against nss-3.67 but it is not yet available in the compose.

https://koji.mbox.centos.org/pkgs/packages/389-ds-base/1.4.3.16/16.module_el8.4.0+845+0c39e1b7/data/logs/x86_64/root.log says nss-3.67, while there is only nss-3.53.1-17.el8_3.x86_64 in the compose: http://mirror.centos.org/centos/8/AppStream/x86_64/os/Packages/nss-3.53.1-17.el8_3.i686.rpm

@carlwgeorge can we get CentOS 8 repo fixed? See previous comment for the details.

Any update on this?
I am affected too.

Thanks

As mentioned we have no control over CentOS. You may want to open a CentOS bug on this, https://bugs.centos.org/

Actually, `CentOS now uses Red Hat's bugzilla. I am going to ping CentOS people out of band myself but please be aware that it is a season for vacations and US just had a long weekend fully of public holidays.

@yellowhat as there was a weekend, and holidays in some places, added that this is a usual period for vacations in the northern hemisphere, I don't think there was too much time/people to look at it yet.

I know this is very annoying, but please, give it a few more days.

For the time being, a workaround that seems to work is to downgrade 389-ds-base to 1.4.3.16-13.

Ok. Thanks for the reply.

Ok, I've been told a bug needs to be raised in bugs.centos.org to untag wrong nss from the buildroot and rebuild 389-ds-base against the correct one.

I opened https://bugs.centos.org/view.php?id=18239 to track this. Closing this one.

Metadata Update from @abbra:
- Issue close_status updated to: invalid
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata