Menu
▾
▴
#190 SERVICE_EXIT_CODE is not properly utilized (fix included)
When running the JSW as a Windows service, there does not appear to be any way to access the exit code if an error occurs during startup. This is an important feature that would allow batch files to query the service status.
e.g., if the JSW exits with an error code of 65, issuing an "sc query <service_name>" with the present JSW returns the following output:
SERVICE_NAME: apia
TYPE : 10 WIN32_OWN_PROCESS
STATE : 1 STOPPED
(NOT_STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 1067 (0x42b)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
The WIN32_EXIT_CODE of 1067 is a generic servic error, but does not indicate the specific code (code 65).
A more useful output would be:
SERVICE_NAME: apia
TYPE : 10 WIN32_OWN_PROCESS
STATE : 1 STOPPED
(NOT_STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 1067 (0x42b)
SERVICE_EXIT_CODE : 65 (0x41)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
where the SERVICE_EXIT_CODE is used to identify the error cause.
wrapper_win.c appears to contain code to set SERVICE_EXIT_CODE, but it has been commented out. Currently, the WIN32_EXIT_CODE is set to the JSW exit code, but since this is not a recognized windows service error, it gets overwritten with the generic 1067 error.
I've attached a unified diff that provides a fix. We've implemented this change in our product, and it works as we'd expect. We can now star the service with a batch file and query to see if it properly started and if not, identify the cause of the problem.
Fix
Logged In: YES
user_id=228081
Originator: NO
Stirling,
Thank you for pointing this out. That was changed in revision 1115, March 8th 2006. It was committed as part of a larger commit and to be honest, I can't remember why. I uncommented that code and am testing it. It appears to be working correctly.
Question though. If I uncomment the code as mentioned in your message above, the Wrapper will always exit with a WIN32 exit code of 0 and a Service exit code of 0 if the JVM exits with an exit code of 0. Any other exit code will result in a WIN32 exit code of 1067 and the Service exit code being the JVM exit code. Is that correct?
1067 means that the service exited unexpectedly. One way of thinking is that any problems with the service itself would result in the 1067 error. But errors from the JVM itself would mean that the Wrapper service exited normally, but the JVM had problems. I am trying to find examples of what other services do. Let me know if you have any comments on how you think it should work.
Cheers,
Leif
Logged In: YES
user_id=228081
Originator: NO
Stirling,
Ok. Looking at this page: http://msdn.microsoft.com/en-us/library/ms685996\(VS.85).aspx
It looks like the service is supposed to set the win32 exit code to ERROR_SERVICE_SPECIFIC_ERROR(1066) when the service specific exit code is being set. This is what the code now does after uncommenting it. Exactly as you posted in your diff.
The problem is that on my machine when I exit the process and query the exit status, it is 1067, NOT 1066. This means that the service exited unexpectedly. I must not be shutting down the service correctly someplace. That is the same exit code as you posted above, so I assume you are also able to reproduce this. I will do some more looking to see if I find out why the 1066 error is changing to a 1067.
Cheers,
Leif
Logged In: YES
user_id=228081
Originator: NO
Stirling,
I got things working. There were a couple more things that needed to get changed beyond your patch to get rid of the 1067 error code problem. Now that it is fixed, if you exit the java app with an exit code of 65, you will get:
SERVICE_NAME: testwrapper
TYPE : 110 WIN32_OWN_PROCESS (interactive)
STATE : 1 STOPPED
(NOT_STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 1066 (0x42a)
SERVICE_EXIT_CODE : 65 (0x41)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
Exiting with an exit code of 0 will result in:
SERVICE_NAME: testwrapper
TYPE : 110 WIN32_OWN_PROCESS (interactive)
STATE : 1 STOPPED
(NOT_STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
This fix will be in the next release.
Thank you for pointing this out.
Cheers,
Leif