Re: [Wrapper-user] Antw: service not starting on Windows 2008R1 64b

[Leif M. <lei...@ta...>]

Javier,
Thank's Hubert for pointing that out.  when you configure environment
variables in the control panel, you can do so SYSTEM WIDE or only for
the current USER.  You need to set them as System environment
variables in order for the SYSTEM user to have access to them.

Cheers,
Leif

On Fri, Jun 11, 2010 at 5:18 PM, Hubert Felber <Hub...@ab...> wrote:
> Silly question:
>
> are the environment variables JAVA_HOME and JRE_HOME correctly set for
> processes running with "system" user ? Do the point to a 64 bit
> JDK/JRE?
>
> Hubert
>
>>>> Javier Muguruza <jav...@at...> 11.06.2010 09:41 >>>
> Leif, our replies inline (>>>>)
>
> Javier,
> When you run with the 32-bit JVM, is that also with the 32-bit
> Wrapper?  Or is it using the same 64-bit Wrapper?
>>>>>
> Yes, before we were using a 32-bit jvm with wrapper-32bit, due to
> memory limitations, we need to change to a x64 bit jdk, so using exactly
> the same folder configuration, we just:
> * Replace wrapper.exe/wrapper.dll/wrapper.jar with the 3.3.0 x64
> versions.
> * Replace jdk with x64 version.
>
>
> If you place the 32-bit Wrapper in the same location as the 64-bit
> Wrapper, it is strange that one would work while the other would not.
> I am not aware of anything in the system which would restrict the use
> of a 64-bit Wrapper vs the 32-bit Wrapper.
>>>>>
> As on a windows 2003R2x64 it is working properly, we are mainly trying
> to check if it may be some security limitation with the SYSTEM account
> on windows 2008, that could affect wrapper.exe behaviour
>
> If a wrapper.log file is never being created, then the problem is
> happening well before the JVM is ever launched, so the configured JVM
> should not matter.  The lack of the wrapper.log indicates that the
> wrapper.exe is never being launched or that it is failing before
> reading in the wrapper.conf file.  In the later case, it would attempt
> to write a wrapper.log into the current directory which would be the
> location of the wrapper.exe.
>>>>>
> We have only seen this file created if we launch on a console the
> wrapper process and we miss some parameter (it asks for the default conf
> file), but not on service start-up
>
> You had said earlier that you get an error in the Event Log, but that
> it was not useful.  Could I see exactly what that message is?  It
> might give me a clue.
>>>>>
> Level: Error Source: Service Contol Manager Eventlog Provider:
> The adam-ManagerProcess service terminated unexpectedly.  It has done
> this 8 time(s).
> - System
>
>  - Provider
>
>   [ Name]  Service Control Manager
>   [ Guid]  {555908D1-A6D7-4695-8E1E-26931D2012F4}
>   [ EventSourceName]  Service Control Manager
>
>  - EventID 7034
>
>   [ Qualifiers]  49152
>
>   Version 0
>
>   Level 2
>
>   Task 0
>
>   Opcode 0
>
>   Keywords 0x80000000000000
>
>  - TimeCreated
>
>   [ SystemTime]  2010-06-10T15:21:23.000Z
>
>   EventRecordID 6870
>
>   Correlation
>
>  - Execution
>
>   [ ProcessID]  0
>   [ ThreadID]  0
>
>   Channel System
>
>   Computer SQAW2K8x64
>
>   Security
>
>
> - EventData
>
>  param1 adam-ManagerProcess
>  param2 8
>
> Windows 2003 was a lot more loose with security.  2008 and Vista both
> introduced much stricter restrictions, including making it impossible
> for the System user to write to the windows directory.
>
> You had confirmed earlier that you could run the 64-bit Wrapper in a
> console correct?  So that would rule out any problem with the binary
> other than a permissions issue.
>
> One thing to try as a test, is to try installing and running the
> service as the same user as you are logged in as.  Please read over
> the following page on how to do this:
> http://wrapper.tanukisoftware.org/doc/english/prop-ntservice-account.html
>
> While this is not a permanent solution, it working or not would give
> clues as to the problem with the SYSTEM user.
>
>>>>>
> Yes, we had already tried this, and it works if we change the logon As
> property on the services for an Administrator account, however this
> would gave us some trouble later on production environments, due to
> password expire policies/etc.
>
> Cheers,
> Leif