Return-Path: X-Original-To: apmail-commons-issues-archive@minotaur.apache.org Delivered-To: apmail-commons-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9A2E6DE95 for ; Thu, 15 Nov 2012 19:25:12 +0000 (UTC) Received: (qmail 95110 invoked by uid 500); 15 Nov 2012 19:25:12 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 95036 invoked by uid 500); 15 Nov 2012 19:25:12 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 95027 invoked by uid 99); 15 Nov 2012 19:25:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Nov 2012 19:25:12 +0000 Date: Thu, 15 Nov 2012 19:25:12 +0000 (UTC) From: "Jess Holle (JIRA)" To: issues@commons.apache.org Message-ID: <1970173131.120501.1353007512301.JavaMail.jiratomcat@arcas> In-Reply-To: <1289271895.11475.1330685939018.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (DAEMON-244) prunsrv does not propagate exit code MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/DAEMON-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13498261#comment-13498261 ] Jess Holle commented on DAEMON-244: ----------------------------------- This is a rather serious gap. Is there any possibility of getting 1.0.11 out the door soon to address this? > prunsrv does not propagate exit code > ------------------------------------ > > Key: DAEMON-244 > URL: https://issues.apache.org/jira/browse/DAEMON-244 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun > Affects Versions: 1.0.10 > Environment: MS Windows > Reporter: Peter Ehrbar > Assignee: Mladen Turk > Fix For: 1.0.11 > > Attachments: exit_code_patch_on_1_0_10.txt, exit_code_patch_on_1_0_10-u.txt > > > In order to perform recovery actions (e.g. restart service) the Windows Service Controller needs to detect abnormal program terminations (failures). The Service controller detects a failure if either the service process crashes or the process terminates with a non-zero exit code. > For my Java server application I want to define recovery actions for the following conditions: > 1) VM crash > 2) Error was thrown (e.g. OutOfMemoryError) > 3) System.exit() with non-zero exit code > When using prunsrv as a wrapper, I observe the following behaviour: > 1) VM crash is detected only when StartMode=jvm, otherwise the Service Controller ignores the failure situation > 2) When an Error is thrown and StartMode=jvm, prunsrv does not terminate but seems to hang. Therefore, the Service Controller is not aware of the failure. For other StartModes, prunsrv terminates, but the Service Controller does not detect the failure. > 3) When System.exit(42) is called, prunsrv terminates but the Service Controller does not detect the non-zero exit code. This applies for all StartModes. > It seems to me as if prunsrv always terminates with exit code zero. But I expect the following behaviour: > 1) VM crash with StartMode=jvm -> OK as it is now, but with other StartModes, prunsrv should terminate with a non-zero exit code in order to indicate the abnormal termination. > 2) When an Error is thrown, prunsrv should terminate with a non-zero exit code in order to indicate the abnormal termination. > 3) When System.exit() is called, prunsrv should terminate with the exit code passed to System.exit() (transparent behaviour), in order to let the application indicate a failure situation. > With the current behaviour, it is not possible to let the Windows Service Controller perform recovery actions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira