Wulf, Along these lines -- in ipaupgrade.log, I see:
2019-11-02T10:55:29Z DEBUG args=['/bin/systemctl', 'start', 'pki-tomcatd@pki-tomcat.service'] 2019-11-02T10:57:00Z DEBUG Process finished, return code=1 2019-11-02T10:57:00Z DEBUG stdout= 2019-11-02T10:57:00Z DEBUG stderr=Job for pki-tomcatd@pki-tomcat.service failed because a timeout was exceeded. See "systemctl status pki-tomcatd@pki-tomcat.service" and "journalctl -xe" for details. However, the pki-tomcat-ca-debug.2019-11-02.log you posted doesn't have any entries from around this time. Additionally, though perhaps a red herring, I see: 2019-11-02T10:55:29Z DEBUG Failed to check CA status: cannot connect to 'http://ipa.mailstation.de:8080/ca/admin/ca/getStatus': [Errno 111] Connection refused So perhaps the Tomcat debug logs from 10:50 -> 11:00 might be a good place to start? Maybe there's an hour shift in there, but I assume the logs would have similar timestamps since they're on the same system. - Alex ----- Original Message ----- > From: "Alexander Bokovoy via FreeIPA-users" > <freeipa-users@lists.fedorahosted.org> > To: "Wulf C. Krueger" <w...@mailstation.de> > Cc: "FreeIPA users list" <freeipa-users@lists.fedorahosted.org>, "Alex > Scheel" <asch...@redhat.com>, "Alexander > Bokovoy" <aboko...@redhat.com> > Sent: Monday, November 4, 2019 11:50:41 AM > Subject: [Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) > fails to start > > On ma, 04 marras 2019, Wulf C. Krueger wrote: > >Hello Alex, > > > >On 2019-11-04 16:49, Alex Scheel via FreeIPA-users wrote: > >>These backtraces from Wulf don't end in JSS at all. In fact, JSS seems to > >>initalize > >>just fine around 2019-11-02 11:55:34 in the Tomcat debug log. This seems > >>like a bug > >>in the LDAPProfileSubsystem of Dogtag. > > > >Thanks for chiming in - any suggestions on how to proceed? > > > >I'm wondering why the LDAP server *only* seems to be listening on that > >socket (cf. log) instead of (or in addition to) ports 389/636. > > I think it is a red herring. ipa-server-upgrade switches off 389/636 > during upgrade to prevent inconsistency leaking out for replication. If > something unexpected happens during the upgrade when these ports were > disabled, they might be left disabled. The question is why it was left > in a state it was left in. > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org > _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
