To help catch common configuration and deployment issues, PPM Center performs basic startup checks before starting. These checks include:
Making sure that essential
server.confparameters are present.
Making sure that none of the ports required by PPM Center are already bound by other processes.
Making sure that all ports used by the nodes on a given physical server have unique values.
Note: Because of these startup checks, you may encounter more configuration errors in 9.50 (and beyond) that prevent a PPM Server from starting (whereas a successful start was allowed on a previous version).
A summary of all issues found during the startup checks is traced out into the server log of the node being started. If PPM Center is running as a Windows service, an error is added to the Windows event log asking you to refer to the server log when errors are found. In some rare cases that the server logs could not provide useful details, we recommend that you start PPM Center in the console mode by using the
kStart.sh script, and then troubleshoot the configuration and deployment issues. After you fix these issues, you can start PPM Center as a Windows service again.
Errors fall into two categories:
Critical errors (Error messages): These errors relate to the node being started. PPM Center will refuse to start if there are any critical errors.
Non-critical errors (Warning messages): These errors relate to other nodes in server.conf than the one being started. It is highly recommended to fix such errors, however they will not prevent the startup. All nodes in the
server.conffile are checked when any one node is started.
By default, the
com.kintana.core.server.BYPASS_STARTUP_CHECKS parameter in the
server.conf file is set to
You can bypass the startup checks by setting this parameter to
Caution: This parameter should only be used under advisement from PPM customer support engineers, and if there is a clear and well-understood reason for doing so.
PPM includes a significant number of improvements to the application startup process, from both a logging and configuration validation standpoint. One of the goals of the improvements is to provide customers with as much information as possible about the validity of the configuration of their clustered environments.
To enable the display of failed server executions at startup, make sure that the
FAIL_EXECUTIONS_ON_STARTUP server configuration parameter is set to
true in the
server.conf file. All executions that were interrupted during the last PPM shut-down are marked as failed.
You can enable the display (and logging) of all PPM server configuration parameters used during startup. To enable this feature, set the
SHOW_PARAMETERS_AT_STARTUP server configuration parameter to
Server startup logs indicate what the server is doing at each step of the startup process (including the successful start of each web context). By default, when the startup check catches a configuration or deployment issue, only a error or warning message will be generated in the server logs. You can modify the logging level to get more details by adding the following entries in the logging.conf file:
com.kintana.core.logging.SYSTEM_THRESHOLD = INFO
com.kintana.core.logging.PRODUCT_FUNCTION_LOGGING_LEVEL = com.kintana.core.server.ServerStartupSanity, INFO
Caution: These parameters are designed for advanced troubleshooting. We do not suggest modifying these parameters without advisement from PPM customer support engineers.