When the Tomcat is started it will run the selftests for each subsystem. Currently if the test fails the engine for the subsystem will not run, but the error will only be shown in the system log, so the admin may not be aware of the failure. Also, the Tomcat server and the web application for that subsystem will continue to run and accept client connections, which can lead to confusions or additional risks.
One solution is to shutdown Tomcat if there's a failure, but this will affect other subsystems running in the same instance.
Another solution is to undeploy the web application of the failing subsystem. This way client will know immediately that the service is unavailable, and other subsystems running on the same instance can still continue to run.
There are several ways to stop/undeploy a web application:
Stopping a subsystem using Tomcat Manager doesn't seem to be permanent. The subsystem will start again when Tomcat is restarted, but then it will stop again if the selftest is still failing. After fixing the problem, the subsystem can be restarted via the Tomcat Manager.
This method seems to be permanent, but it requires direct access to the file system. Redeploying the subsystem requires recreating the context.xml.
is this a dupe of this? https://fedorahosted.org/pki/ticket/947 Startup should fail if self tests fail.
I think #947 is a duplicate of this ticket, but when deciding the solution we need to consider how IPA will be able to detect selftest errors.
Proposed Milestone: 10.2.3 (per CS Meeting of 09/17/2014)
[PKI TRAC Ticket #947 - Startup should fail if self tests fail.] marked as duplicate of https://fedorahosted.org/pki/ticket/745 PKI TRAC Ticket #745 - Service should not start if selftest fails (per CS Meeting of 09/17/2014)
proposed Milestone: 10.2.3 - Per Dogtag 10.2.3 meeting of 09/25/2014
Per Dogtag 10.2.X meeting of 01/14/2015: Milestone 10.2.2
master: 22ff1fbd2de37395e219a7e7362722517a3f4dc3
Metadata Update from @edewata: - Issue assigned to edewata - Issue set to the milestone: 10.2.2
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/1312
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.