Menu
▾
▴
Re: [Wrapper-user] Antw: service not starting on Windows 2008R1 64b
|
From: Leif M. <lei...@ta...> - 2010-06-11 09:57:57
|
Javier
> [Javier Muguruza]
> With wrapper.exe x32 we do see wrapper.log files (we have it renamed to service-name.service.log files), depending on the log level we have selected on the wrapper. We do not see the one on the wrapper-bin folder, we have only seen this created when we send a wrong parameter to wrapper.exe during testing
Ok. So you are not seeing the service-name.service.log file when
running as a 64-bit Service.
> [Javier Muguruza] do I send it to some other email address? I guess attachment will get stripped here?
Please CC me directly along with the list. Then it will be sure to
make it to me.
> [Javier Muguruza] We had this on ERROR, however no additional info has been added to the event once changed to debug
This is when running as the 64-bit Wrapper? That is just one more
piece of evidence that the Wrapper.exe is never being launched.
Thanks.
> [Javier Muguruza]
> This makes somehow sense, but env variables where defined before we were using x32 jdk and wrapper, and where not changed when we move to the x64 bit versions, however I think something like this may be what is happening
>
> Regarding envvars, yes, we have JDK_HOME as system variable. We don't have a JRE_HOME defined but I don't think it's needed?
The JRE_HOME or JAVA_HOME variables are not needed by the Wrapper. It
would only be an issue if you are referencing them in your
wrapper.conf file. I will see that when you send it over.
Thanks in advance,
Cheers,
Leif
On Fri, Jun 11, 2010 at 6:17 PM, Javier Muguruza
<jav...@at...> wrote:
>> -----Original Message-----
>> From: Leif Mortenson [mailto:lei...@ta...]
>> Sent: viernes, 11 de junio de 2010 10:00
>> To: wra...@li...
>> Subject: Re: [Wrapper-user] Antw: service not starting on Windows
>> 2008R1 64b
>>
>> Javier,
>> Thank you for your answers.
>>
>> You said that when running the 32-bit Wrapper on 2008, you are NOT
>> seeing a wrapper.log file when running as a Service? Or were you
>> referring to the wrapper.log that can be created in the wrapper.exe's
>> directory?
> [Javier Muguruza]
> With wrapper.exe x32 we do see wrapper.log files (we have it renamed to service-name.service.log files), depending on the log level we have selected on the wrapper. We do not see the one on the wrapper-bin folder, we have only seen this created when we send a wrong parameter to wrapper.exe during testing
>
>>
>> I should have asked you a long time ago, but would it be possible for
>> you send me your wrapper.conf file?
> [Javier Muguruza] do I send it to some other email address? I guess attachment will get stripped here?
>
>>
>> Thank you for the Event Log output. Unfortunately, I agree, it is not
>> very useful. It does however confirm that the Wrapper binary is
>> either not being launched or immediately failing.
>>
>> It won't help if the Wrapper is not starting or exiting immediately,
>> but it might be useful to try setting the following. It will cause
>> the Wrapper to also log to the EventLog. This will only happen if it
>> is completing the read of the wrapper.conf file however:
>> wrapper.syslog.loglevel=DEBUG
> [Javier Muguruza] We had this on ERROR, however no additional info has been added to the event once changed to debug
>
>>
>> The fact that the service runs as a Service when run as the
>> Administrator proves that the Wrapper binary itself is fine. It also
>> shows that the wrapper.conf is most likely correct.
>> When you do this, do you get a wrapper.log file in the expected
>> location?
>> >From this information, this narrows it down to one of two problems. 1)
>> An environment difference like the PATH or JAVA_HOME variables, or 2)
>> a directory access problem. If it is 1, it would not explain the
>> lack of the wrapper.log file.
> [Javier Muguruza]
> This makes somehow sense, but env variables where defined before we were using x32 jdk and wrapper, and where not changed when we move to the x64 bit versions, however I think something like this may be what is happening
>
>
> Regarding envvars, yes, we have JDK_HOME as system variable. We don't have a JRE_HOME defined but I don't think it's needed?
> Javier
>
>>
>> Cheers,
>> Leif
>>
>> On Fri, Jun 11, 2010 at 4:41 PM, Javier Muguruza
>> <jav...@at...> wrote:
>> > 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
|
