[jboss-jira] [JBoss JIRA] (WFLY-10362) Propagation of exit code to Windows Service Control Manager
Marat Abrarov (JIRA)
issues at jboss.org
Sat May 12 12:48:00 EDT 2018
[ https://issues.jboss.org/browse/WFLY-10362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marat Abrarov updated WFLY-10362:
---------------------------------
Release Notes Text: If pull request #3293 (https://github.com/wildfly/wildfly-core/pull/3293) is taken as is then existing Windows service (installed before this change) needs to be reinstalled because start parameter of Procrun is modified (additional environment variable is added - ISSERVICE) in new service.bat and ISSERVICE is required for correct transformation of exit code by modified domain.bat and standalone.bat. (was: If pull request #3293 (https://github.com/wildfly/wildfly-core/pull/3293) is taken as is then existing Windows service (installed before this change) needs to be reinstalled because new start parameter (additional environment variable - ISSERVICE) of Procrun is added in new service.bat and ISSERVICE is required for correct transformation of exit code by modified domain.bat and standalone.bat.)
> Propagation of exit code to Windows Service Control Manager
> -----------------------------------------------------------
>
> Key: WFLY-10362
> URL: https://issues.jboss.org/browse/WFLY-10362
> Project: WildFly
> Issue Type: Enhancement
> Components: Scripts
> Reporter: Marat Abrarov
>
> I use JBoss / WildFly as Windows service (wildfly-service.exe, aka prunsrv.exe, aka Apache Commons Daemon Procrun) and face multiple issues which prevents Windows service [recovery actions|https://msdn.microsoft.com/en-us/library/windows/desktop/ms685939(v=vs.85).aspx] to work as expected for my WildFly / JBoss Windows service - Windows Service Control Manager (SCM) just doesn't understand that WildFly Windows service failed if my WildFly crashes (for example, in case of OOM and {{-XX:+CrashOnOutOfMemoryError}} JVM option), and SCM doesn't execute recovery actions at all.
> Below is the list of issues I found being the root cause:
>
> # WildFly (JBoss) launch scripts (domain.bat and standalone.bat) don't return exit code of JVM to the caller sometimes (depends on the way scripts are launched). They should explicitly use
> {code}
> exit /B my_exit_code
> {code}
> to return exit code to the caller always.
> # Procrun (wildfly-service.exe) [reports about stopped state|https://issues.apache.org/jira/browse/DAEMON-243?focusedCommentId=16462803&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16462803] of Windows service even if JVM process stops with non zero exit code (but this exit code is still returned to SCM).
> # Procrun and WildFly service.bat script don't turn on [failure actions flag|https://msdn.microsoft.com/en-us/library/ms685937(v=vs.85).aspx] for the Windows service which is installed by their means. Because of this flag is turned off SCM doesn't treat the case when stopped state is reported with non zero exit code as service failure.
> I suggest to:
> # Change service.bat - add turning on of failure actions flag for the service installed by Procrun.
> # Change service.bat - add additional flag (environment variable) to indicate that WildFly is running as Windows service. This flag is needed for transformation of exit code - we cannot use exit codes 1..15999 because of Procrun doesn't define its own error messages and Windows Service Control Manager (SCM) treats exit code reported by Procrun as standard Windows [System Error Code|https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx], so we need to modify exit code reported by Procrun (exit code of WildFly launch script) to make it not interleaving with existing Windows System Error Codes.
> # Change standalone.bat and domain.bat (PowerShell scripts are not used for Windows services) to explicitly return non zero exit code in case of errors. This error code should be adjusted if WildFly runs as Windows service (refer to additional flag introduced as Procrun start parameter in service.bat and described above).
> Refer to [pull request #3293|https://github.com/wildfly/wildfly-core/pull/3293] at wildfly/wildfly-core GitHub project.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
More information about the jboss-jira
mailing list