Menu
▾
▴
Re: [Wrapper-user] Antw: service not starting on Windows 2008R1 64b
|
From: Javier M. <jav...@at...> - 2010-06-11 09:16:51
|
> -----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
>
> -----------------------------------------------------------------------
> -------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
|
