Cannot start Java app as a service but works fine via command prompt 1

[surfjungle]

Hi there,

I'm having a problem running a Windows Server 2008 service. The strange thing is that it works fine via the command prompt.

I'm running 64-bit Windows Server 2008 SP2 as an VMware image on a EM64T ESX Server. On this server, I'm running 32-bit Java5 from IBM and 32-bit MS Word 2007. I compile and run my Java application with IBM's 32-bit Java5. The application is trying to create a document and is using, amongst other things, the IBM bridge2java.dll and MS Word 2007.

After setting up my classpath, running the following from the command prompt works fine: <java.exe myjavapackage.MyJavaClass 1 1 1>.

However, when I create the service using the following command: <sc.exe create MySimpleService binPath= "java.exe myjavapackage.MyJavaClass 1 1 1" DisplayName= "MySimpleService"> and then try to start it, I get the following message box from Windows: "Windows could not start the MySimpleService service on Local Computer. Error 1053: The service did not respond to the start or control request in a timely fashion". However, know part of the Java application is running as MS Word's WINWORD.EXE process is listed in the Task Manager. There seems to be nothing helpful in the Event Viewer.

I can successfully run the above via the command line AND as a Windows service in 32-bit Windows XP SP3.

The following is a list where one or more of may be causing the issue (or something I haven't thought of):
- DEP / Data Execution Prevention. Have to look into this more.
- Elevated privileges issue. Have to look into this more.
- Service access control list / startup mode / account. Have to look into this more.
- UAC issue. I turned this off from msconfig->Tools, restarted the server - I tried to run the service, again to no avail.
- File security. For java.exe and java jars etc, I added the user which starts the service, to have full control over those files it uses, to no avail.
- Security tab of the Properties of the java.exe and java jars etc is not set correctly for the logged in user. (Set these to full control for the user bound to the service to no avail).
- Something else which I have not thought of.

Any ideas? I'm out of office on holidays next week and will respond to posts when I get back on Monday, the 14th of June.

Thanks in advance for any help - much appreciated... : )

- Jason.

 

[TonHu]

Search google for "java as a windows service"should find you an (old) executable that can start your java app as a service. We use it occasionally to run a full JBoss as a service... but that is with Sun's JRE.

 

[kmcferrin]

I'm not sure that this is going to work because you're running 32-bit Java on 64-bit Windows. It would definitely run fine from the command prompt because the system would catch the 32-bit Java and run it in WOW64 (the 32-bit compatibility layer). But I'm pretty sure that all applications that run as a service need to be 64-bit on 64-bit Windows. I know that it is true of device drivers, and I can't see why they would allow 32-bit services on a 64-bit OS.

Have you tried using the 64-bit version of Java?

________________________________________
CompTIA A+, Network+, Server+, Security+
MCTS:Windows 7
MCSE:Security 2003
MCITP:Server Administrator
MCITP:Enterprise Administrator
MCITP:Virtualization Administrator 2008 R2
Certified Quest vWorkspace Administrator

 

[TonHu]

I'm running 32 bit service apps fine on 64 bit Windows over here, and also no problems running my 32 bit JRE on 64 bit Windows as a service.

The 64 bit restrictions you name is (only) true for device drivers, but not services.
Be aware the WOW64 subsystem needs to be installed on W2K8r2, but it apparently is on your system as the app runs from the command line.

 

[kmcferrin]

I am guessing that whether it runs correctly as a service would depend on how it interacts with the system. For example:

32-bit applications that include only 32-bit kernel-mode device drivers, or that plug into the process space of components that are implemented purely as 64-bit processes (e.g. Windows services or Windows Explorer) cannot be executed on a 64-bit platform.
Internet Explorer is implemented as both a 32-bit and a 64-bit application because of the large number of 32-bit ActiveX components on the internet that would not be able to plug into the 64-bit version.

From the WOW64 Wikipedia page.

________________________________________
CompTIA A+, Network+, Server+, Security+
MCTS:Windows 7
MCSE:Security 2003
MCITP:Server Administrator
MCITP:Enterprise Administrator
MCITP:Virtualization Administrator 2008 R2
Certified Quest vWorkspace Administrator

 

[surfjungle]

Thank you TonHu and kmcferrin for your responses...

@ TonHu - regarding "the old executable" - are you talking about the Java Service Wrapper?

@ kmcferrin - alas, we can't use 64-bit Java as we must use the 32-bit IBM JDK that comes with WebSphere (for our customer). I'll test it on the 64-bit Java when I get back to verify though.

I'll be back on the 14th to try the above - thanks again.

Jason

 

[TonHu]

Can't recall what the exact exe was, I'm not with/near that project any longer, but it sure does look a lot like that.
An alternative could be 'yajsw', at

http://yajsw.sourceforge.net/

 

[surfjungle]

@ kmcferrin - after trying to test the above with Sun's JDK 1.5.0_11 64-bit - recompiled the classes and jar'd them up. After trying to run the app - it fell over as the bridge2java.dll is 32-bit which gives me the following exception:

Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Windows\System32\bridge2java.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform

I can't seem to find a 64-bit version of it so that's off the table for now.

As an aside There's an interesting article regarding accessing 32-bit dll's from 64-bit code but it's quite involved:

http://www.dnjonline.com/article.aspx?id=jun07_access3264

I will keep working on this - if I figure it out, I'll post it.

Any other relevant suggestions are appreciated...

Thanks, Jason.

 

[surfjungle]

Hi there,

Just to give ye the official IBM word, straight from the horses mouth on WebSphere Application Server instances registered as Windows services. This is peripheral but perhaps relevant to my problem above.

When setting up a WebSphere Application Server Network Deployment environment on Windows, we have the following:
1. deployment manager (dmgr). This is OK to have as a Windows service.
2. nodeagent. This is OK to have as a Windows service.
3. Application server instance (default: <server1>). This is NOT OK to have as a Windows service.

The WebSphere Application Server instance, for example the default is named <server1>, should NOT be ran as a windows service as it is managed by the nodeagent. Each application server instance which is managed by the nodeagent, can be configured to start with the nodeagent. Thus by making both the deployment manager (dmgr) and the nodeagent Windows services, any application server instance managed by said nodeagent will start with the nodeagent service. Note that the services login user for both the deployment manager and nodeagent should be set to <Local System Account>. This allows one to start the deployment manager, nodeagent and application service instance via Windows services, which can be set to automatic to allow every to start when the machine starts, thus not requiring a user to be logged in. See the following for more info:

http://publib.boulder.ibm.com/infoc...phere.nd.doc/info/ae/ae/urun_rmonitorpol.html

Tips:

#1: If either the deployment manager or nodeagent is registered as a service and an attempt to start them is made via the startManager or startNode BAT files, WebSphere will try to start the services. To cleanly start these servers via a BAT file, they must be unregistered as Windows Services.

#2: When dealing with Windows services - creating, deleting and editing, it is highly recommended that the following tool (WASServiceCmd) is used:

http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21397335

- Jason.

 

[surfjungle]

Hi all,

As promised, the solution to the core issue we've been having with 32-bit WebSphere Application Server Network Deployment v6.1.0.27 running on 64-bit Windows Server 2008 SP1 with IBM's old bridge2java.dll file (not supported since 2004). My colleague found the fix which was ridiculously simple in the end:

For Windows 2008 64-Bit create the following directory:
C:\Windows\SysWOW64\config\systemprofile\desktop

For Windows 2008 32-Bit create the following directory
C:\Windows\System32\config\systemprofile\desktop

Register the dmgr and nodeagent as services using WASServiceCmd.exe if not already done so. Set the monitoring policy of the application server/s to start up with the nodeagent so that everythings can start after without logging in as per my previous post and presto, it works. My colleague has successfully tested this with the 64-bit version of Windows Server 2008 and will shortly be doing this for the 32-bit version.

So, there you have it... missing directories...

The unfortunate thing is that the solution to our core issue and the title of this post are quite dissimilar but I hope it helps somebody else : )


- Jason.