You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(13) |
Nov
(16) |
Dec
(29) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(38) |
Feb
(51) |
Mar
(51) |
Apr
(115) |
May
(82) |
Jun
(30) |
Jul
(50) |
Aug
(68) |
Sep
(57) |
Oct
(160) |
Nov
(80) |
Dec
(78) |
| 2004 |
Jan
(71) |
Feb
(75) |
Mar
(108) |
Apr
(87) |
May
(79) |
Jun
(70) |
Jul
(69) |
Aug
(39) |
Sep
(52) |
Oct
(47) |
Nov
(50) |
Dec
(32) |
| 2005 |
Jan
(22) |
Feb
(122) |
Mar
(46) |
Apr
(76) |
May
(31) |
Jun
(51) |
Jul
(61) |
Aug
(70) |
Sep
(37) |
Oct
(46) |
Nov
(57) |
Dec
(83) |
| 2006 |
Jan
(55) |
Feb
(81) |
Mar
(51) |
Apr
(67) |
May
(77) |
Jun
(43) |
Jul
(106) |
Aug
(64) |
Sep
(47) |
Oct
(64) |
Nov
(60) |
Dec
(12) |
| 2007 |
Jan
(50) |
Feb
(93) |
Mar
(49) |
Apr
(56) |
May
(40) |
Jun
(63) |
Jul
(40) |
Aug
(47) |
Sep
(54) |
Oct
(37) |
Nov
(54) |
Dec
(37) |
| 2008 |
Jan
(35) |
Feb
(39) |
Mar
(26) |
Apr
(14) |
May
(23) |
Jun
(51) |
Jul
(43) |
Aug
(26) |
Sep
(29) |
Oct
(31) |
Nov
(24) |
Dec
(16) |
| 2009 |
Jan
(21) |
Feb
(30) |
Mar
(74) |
Apr
(26) |
May
(26) |
Jun
(43) |
Jul
(23) |
Aug
(23) |
Sep
(15) |
Oct
(27) |
Nov
(37) |
Dec
(10) |
| 2010 |
Jan
(16) |
Feb
(28) |
Mar
(16) |
Apr
(45) |
May
(8) |
Jun
(68) |
Jul
(45) |
Aug
(44) |
Sep
(51) |
Oct
(7) |
Nov
(20) |
Dec
(21) |
| 2011 |
Jan
(14) |
Feb
(17) |
Mar
(7) |
Apr
(7) |
May
(48) |
Jun
(23) |
Jul
(5) |
Aug
(33) |
Sep
(22) |
Oct
(14) |
Nov
(14) |
Dec
(5) |
| 2012 |
Jan
|
Feb
(10) |
Mar
(12) |
Apr
(51) |
May
(10) |
Jun
(8) |
Jul
(14) |
Aug
(22) |
Sep
(9) |
Oct
(24) |
Nov
(14) |
Dec
(13) |
| 2013 |
Jan
(12) |
Feb
(4) |
Mar
(14) |
Apr
(19) |
May
(2) |
Jun
(5) |
Jul
(13) |
Aug
(10) |
Sep
(4) |
Oct
(11) |
Nov
(13) |
Dec
(2) |
| 2014 |
Jan
(3) |
Feb
(14) |
Mar
(5) |
Apr
(10) |
May
(10) |
Jun
(11) |
Jul
(10) |
Aug
(3) |
Sep
(13) |
Oct
(22) |
Nov
(14) |
Dec
(32) |
| 2015 |
Jan
(8) |
Feb
(2) |
Mar
(17) |
Apr
(1) |
May
(24) |
Jun
|
Jul
(4) |
Aug
|
Sep
(9) |
Oct
(9) |
Nov
(5) |
Dec
(2) |
| 2016 |
Jan
(8) |
Feb
(6) |
Mar
(6) |
Apr
(9) |
May
(3) |
Jun
(2) |
Jul
(7) |
Aug
(6) |
Sep
|
Oct
|
Nov
(1) |
Dec
(6) |
| 2017 |
Jan
(9) |
Feb
(8) |
Mar
(6) |
Apr
|
May
|
Jun
(3) |
Jul
(13) |
Aug
(10) |
Sep
(8) |
Oct
|
Nov
(6) |
Dec
|
| 2018 |
Jan
|
Feb
(5) |
Mar
(7) |
Apr
(2) |
May
|
Jun
|
Jul
(3) |
Aug
(2) |
Sep
(9) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2019 |
Jan
(9) |
Feb
|
Mar
|
Apr
(10) |
May
(3) |
Jun
|
Jul
(7) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2020 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2021 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2023 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Leif M. <lei...@ta...> - 2010-06-18 03:14:30
|
Juan,
Thank for the information. From the screen shots, the closing of
your Swing GUI is causing the Wrapper to shutdown correct? Are you
seeing a black console window at all? I know we had issues with that
in the past, but with the default settings, I believed that they were
resolved.
Could you please set the wrapper.debug=true property and retest this?
Then send me the resulting wrapper.log file directly. Please make a
note of the time that you close your application if it is not obvious.
The Wrapper.log should let me see exactly why it is shutting down.
Thanks in advance,
Cheers,
Leif
On Fri, Jun 18, 2010 at 1:01 AM, Juan Sanchez <jsa...@pu...> wrote:
> Hi Lief, thanks for the reply.
> Wrapper version 3.3.9.0 Windows XP Java 1.6
>
> here is my wrapper.conf
>
> wrapper.java.command=java
> wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
> wrapper.java.classpath.1=dist/lib/wrappertest.jar
> wrapper.java.classpath.2=dist/lib/wrapper.jar
> wrapper.java.classpath.3=dist/lib/jna.jar
> wrapper.java.classpath.4=dist/lib/jdom.jar
> wrapper.java.classpath.5=dist/lib/mysql-connector-java-5.1.7-bin.jar
> wrapper.java.classpath.6=dist/MonitorLanCenter.jar
> wrapper.java.library.path.1=lib
> wrapper.java.additional.auto_bits=TRUE
> wrapper.java.initmemory=64
> wrapper.java.maxmemory=512
> wrapper.app.parameter.1=com.monitor.lancenter.Main
> wrapper.console.format=PM
> wrapper.console.loglevel=INFO
> wrapper.logfile=logs/wrapper.log
> wrapper.logfile.format=LPTM
> wrapper.logfile.loglevel=INFO
> wrapper.logfile.maxsize=100k
> wrapper.logfile.maxfiles=0
> wrapper.syslog.loglevel=NONE
> wrapper.ignore_sequence_gaps=TRUE
> wrapper.console.title=MonitorLanCenterServicio
> wrapper.name=MonitorLanCenterServicio
> wrapper.displayname=MonitorLanCenterServicio
> wrapper.description=MonitorLanCenterServicio
> wrapper.ntservice.dependency.1=
> wrapper.ntservice.starttype=AUTO_START
> wrapper.ntservice.interactive=TRUE
> # I aggregate the ones below 'cause I thought helped me
> wrapper.ntservice.hide_console=TRUE
> wrapper.ntservice.console=FALSE
> wrapper.ntservice.generate_console=FALSE
>
> remembering my problem. when the service runs abviously the process is un
> background and work all ok, but when the GUI appears (JFrame) I can close
> that , so if I do it the services automatically STOP. and that is my problem
> ... the service MUST NOT stop, even if the user close the GUI.
> I adjunt a screen shot of my problem to explain better.
> I hope to helped me. Thanks in advance.
>
> Juan
|
|
From: Juan S. <jsa...@pu...> - 2010-06-17 16:01:42
|
Hi Lief, thanks for the reply. Wrapper version 3.3.9.0 Windows XP Java 1.6 here is my wrapper.conf wrapper.java.command=java wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp wrapper.java.classpath.1=dist/lib/wrappertest.jar wrapper.java.classpath.2=dist/lib/wrapper.jar wrapper.java.classpath.3=dist/lib/jna.jar wrapper.java.classpath.4=dist/lib/jdom.jar wrapper.java.classpath.5=dist/lib/mysql-connector-java-5.1.7-bin.jar wrapper.java.classpath.6=dist/MonitorLanCenter.jar wrapper.java.library.path.1=lib wrapper.java.additional.auto_bits=TRUE wrapper.java.initmemory=64 wrapper.java.maxmemory=512 wrapper.app.parameter.1=com.monitor.lancenter.Main wrapper.console.format=PM wrapper.console.loglevel=INFO wrapper.logfile=logs/wrapper.log wrapper.logfile.format=LPTM wrapper.logfile.loglevel=INFO wrapper.logfile.maxsize=100k wrapper.logfile.maxfiles=0 wrapper.syslog.loglevel=NONE wrapper.ignore_sequence_gaps=TRUE wrapper.console.title=MonitorLanCenterServicio wrapper.name=MonitorLanCenterServicio wrapper.displayname=MonitorLanCenterServicio wrapper.description=MonitorLanCenterServicio wrapper.ntservice.dependency.1= wrapper.ntservice.starttype=AUTO_START wrapper.ntservice.interactive=TRUE # I aggregate the ones below 'cause I thought helped me wrapper.ntservice.hide_console=TRUE wrapper.ntservice.console=FALSE wrapper.ntservice.generate_console=FALSE remembering my problem. when the service runs abviously the process is un background and work all ok, but when the GUI appears (JFrame) I can close that , so if I do it the services automatically STOP. and that is my problem ... the service MUST NOT stop, even if the user close the GUI. I adjunt a screen shot of my problem to explain better. I hope to helped me. Thanks in advance. Juan |
|
From: Leif M. <lei...@ta...> - 2010-06-16 23:37:51
|
Juan, Which version of the Wrapper, Windows, and Java are you using? Would it be possible to send me a screen shot of what you are seeing along with your wrapper.conf file? Thanks, Leif On Thu, Jun 17, 2010 at 3:35 AM, Juan Sanchez <jsa...@pu...> wrote: > hello, I have the community version, and my application has GUI > (JFrames) that appear sometimes. My problem is that when they appear, > something like a console black windows but really I do not have a black > windows, I have a program bar that appear, so I can make right click, > close and I think that only close the GUI but the service stop > automatically! plz help , how could I do to not show that program bar, > or how to not to stop the service closing the windows... my services > must not stop... plz help > > regards from Peru |
|
From: Joey G. <jo...@su...> - 2010-06-16 22:51:06
|
Well, if your calling system.exit it will close your program and stop the service. So you probably need to just hide the jframe when they click close. On Wed, Jun 16, 2010 at 1:35 PM, Juan Sanchez <jsa...@pu...> wrote: > hello, I have the community version, and my application has GUI > (JFrames) that appear sometimes. My problem is that when they appear, > something like a console black windows but really I do not have a black > windows, I have a program bar that appear, so I can make right click, > close and I think that only close the GUI but the service stop > automatically! plz help , how could I do to not show that program bar, > or how to not to stop the service closing the windows... my services > must not stop... plz help > > regards from Peru > > > ------------------------------------------------------------------------------ > 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 > |
|
From: Juan S. <jsa...@pu...> - 2010-06-16 18:53:31
|
hello, I have the community version, and my application has GUI (JFrames) that appear sometimes. My problem is that when they appear, something like a console black windows but really I do not have a black windows, I have a program bar that appear, so I can make right click, close and I think that only close the GUI but the service stop automatically! plz help , how could I do to not show that program bar, or how to not to stop the service closing the windows... my services must not stop... plz help regards from Peru |
|
From: Javier M. <jav...@at...> - 2010-06-16 07:30:24
|
One more datapoint, we downloaded wrapper 3.4.1 Standard 64b and tried with TestWrapper. The service starts and we can see the log file, it fails stops straight away cause we don't have a license for it, but it starts and writes to the log... So this problem we see might have been solved since 3.3.0? javier > -----Original Message----- > From: Javier Muguruza [mailto:jav...@at...] > Sent: martes, 15 de junio de 2010 18:45 > To: wra...@li... > Subject: Re: [Wrapper-user] Antw: service not starting on Windows > 2008R1 64b > > Leif, > > Here are the results of the tests you asked. > Thanks > javier > > > 1) The configured wrapper.log file location depends on an environment > > variable. > > > wrapper.logfile=E:\ADAM\adam/runtime/logs/%ADAM_PROCESS_NAME%.service.l > > og.ROLLNUM > > That is being set in the parent configuration file, so it should be > > fine, but could you please try a simple logfile like the following: > > wrapper.logfile=C:¥TEMP¥wrapper.log > > Where that directory is known to exist. I would like to see if you > > get a configuration file in this case. > [Javier Muguruza] > %ADAM_PROCESS_NAME% is not an env. variable, it's defined in the last > conf file, (set.ADAM_PROCESS_NAME=ManagerProcess), anyway, we have set > this to a common existing dir. As before, it was not created when > starting the service. > > > > > 2) Could you please try downloading the wrapper distribution and then > > installing the default TestWrapper application as a service to see > > what happens? If that is having the same problem then we know that > > it is not something to do with your configuration. > [Javier Muguruza] > We have done that and we get the same behaviour, it does not start as a > service with SYSTEM account. > > > > 3) You have the following property configured, but I do not see where > > you are defining ADAM_RUNTIME > > wrapper.java.additional.4=-XX:HeapDumpPath=%ADAM_RUNTIME%/logs > > If that did not exist then it might cause the JVM to fail to start. > > But You should be seeing a wrapper.log with other output long before > > the JVM is launched. > [Javier Muguruza] > In this case %ADAM_RUNTIME% IS an env. variable, we have modified that > line to be > wrapper.java.additional.4=-DHeapDumpPath=%ADAM_RUNTIME%/logs > so it cannot possible throw some error, still the same result. > > > > > > You asked about a newer version of the Wrapper. What version are you > > using? I am not aware of anything in a newer version that would > > correct what you are seeing. I am still quite puzzled as to why the > > Wrapper32 bit version is working but the Wrapper64 bit version is > not. > > The fact that the Wrapper 64-bit works when running as the > > Administrator user proves that the Wrapper binary itself is fine and > > that the configuration is correct. The only differences left are > > permissions, and environment differences. I am not aware of any > > permission configurations which would prevent a 64-bit program from > > running, but allow a 32-bit program. > > > > Please let me know the results of 1-3 above. If they all fail, lets > > set up a phone or Skype meeting to walk through what could be > > happening and try to get this resolved. > > > > Cheers, > > Leif > > > > On Tue, Jun 15, 2010 at 10:25 PM, Javier Muguruza > > <jav...@at...> wrote: > > > Hi, is there anything else we could try? Using a newer version of > > wrapper or anything? > > > > > > Thanks > > > javier > > > > -- > > Leif Mortenson > > Tanuki Software, Ltd. > > 6-16-7-1001 Nishi-Kasai, Edogawa-ku > > Tokyo 134-0088 Japan > > Tel/Fax: +81-3-3878-3211 > > http://www.tanukisoftware.com > > lei...@ta... > > > > --------------------------------------------------------------------- > -- > > ------- > > 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 > > ----------------------------------------------------------------------- > ------- > 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 |
|
From: Javier M. <jav...@at...> - 2010-06-15 16:44:03
|
Leif, Here are the results of the tests you asked. Thanks javier > 1) The configured wrapper.log file location depends on an environment > variable. > wrapper.logfile=E:\ADAM\adam/runtime/logs/%ADAM_PROCESS_NAME%.service.l > og.ROLLNUM > That is being set in the parent configuration file, so it should be > fine, but could you please try a simple logfile like the following: > wrapper.logfile=C:¥TEMP¥wrapper.log > Where that directory is known to exist. I would like to see if you > get a configuration file in this case. [Javier Muguruza] %ADAM_PROCESS_NAME% is not an env. variable, it's defined in the last conf file, (set.ADAM_PROCESS_NAME=ManagerProcess), anyway, we have set this to a common existing dir. As before, it was not created when starting the service. > > 2) Could you please try downloading the wrapper distribution and then > installing the default TestWrapper application as a service to see > what happens? If that is having the same problem then we know that > it is not something to do with your configuration. [Javier Muguruza] We have done that and we get the same behaviour, it does not start as a service with SYSTEM account. > 3) You have the following property configured, but I do not see where > you are defining ADAM_RUNTIME > wrapper.java.additional.4=-XX:HeapDumpPath=%ADAM_RUNTIME%/logs > If that did not exist then it might cause the JVM to fail to start. > But You should be seeing a wrapper.log with other output long before > the JVM is launched. [Javier Muguruza] In this case %ADAM_RUNTIME% IS an env. variable, we have modified that line to be wrapper.java.additional.4=-DHeapDumpPath=%ADAM_RUNTIME%/logs so it cannot possible throw some error, still the same result. > > You asked about a newer version of the Wrapper. What version are you > using? I am not aware of anything in a newer version that would > correct what you are seeing. I am still quite puzzled as to why the > Wrapper32 bit version is working but the Wrapper64 bit version is not. > The fact that the Wrapper 64-bit works when running as the > Administrator user proves that the Wrapper binary itself is fine and > that the configuration is correct. The only differences left are > permissions, and environment differences. I am not aware of any > permission configurations which would prevent a 64-bit program from > running, but allow a 32-bit program. > > Please let me know the results of 1-3 above. If they all fail, lets > set up a phone or Skype meeting to walk through what could be > happening and try to get this resolved. > > Cheers, > Leif > > On Tue, Jun 15, 2010 at 10:25 PM, Javier Muguruza > <jav...@at...> wrote: > > Hi, is there anything else we could try? Using a newer version of > wrapper or anything? > > > > Thanks > > javier > > -- > Leif Mortenson > Tanuki Software, Ltd. > 6-16-7-1001 Nishi-Kasai, Edogawa-ku > Tokyo 134-0088 Japan > Tel/Fax: +81-3-3878-3211 > http://www.tanukisoftware.com > lei...@ta... > > ----------------------------------------------------------------------- > ------- > 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 |
|
From: Javier M. <jav...@at...> - 2010-06-15 15:43:26
|
Thanks Leif, we'll try 1-3 asap but wanted to let you know the version info. I think I mentioned in my first email, but here it is again, we have wrapper-3.3.0, Standard Edition. If you would like us to try a newer one let me know javier > -----Original Message----- > From: Leif Mortenson [mailto:lei...@ta...] > Sent: martes, 15 de junio de 2010 16:58 > To: wra...@li... > Subject: Re: [Wrapper-user] Antw: service not starting on Windows > 2008R1 64b > > Javier, > Sorry for the delay getting back to you. We reviewed your > wrapper.conf files and there are a few things I would like to ask you > to try out. > > 1) The configured wrapper.log file location depends on an environment > variable. > wrapper.logfile=E:\ADAM\adam/runtime/logs/%ADAM_PROCESS_NAME%.service.l > og.ROLLNUM > That is being set in the parent configuration file, so it should be > fine, but could you please try a simple logfile like the following: > wrapper.logfile=C:¥TEMP¥wrapper.log > Where that directory is known to exist. I would like to see if you > get a configuration file in this case. > > 2) Could you please try downloading the wrapper distribution and then > installing the default TestWrapper application as a service to see > what happens? If that is having the same problem then we know that > it is not something to do with your configuration. > > 3) You have the following property configured, but I do not see where > you are defining ADAM_RUNTIME > wrapper.java.additional.4=-XX:HeapDumpPath=%ADAM_RUNTIME%/logs > If that did not exist then it might cause the JVM to fail to start. > But You should be seeing a wrapper.log with other output long before > the JVM is launched. > > You asked about a newer version of the Wrapper. What version are you > using? I am not aware of anything in a newer version that would > correct what you are seeing. I am still quite puzzled as to why the > Wrapper32 bit version is working but the Wrapper64 bit version is not. > The fact that the Wrapper 64-bit works when running as the > Administrator user proves that the Wrapper binary itself is fine and > that the configuration is correct. The only differences left are > permissions, and environment differences. I am not aware of any > permission configurations which would prevent a 64-bit program from > running, but allow a 32-bit program. > > Please let me know the results of 1-3 above. If they all fail, lets > set up a phone or Skype meeting to walk through what could be > happening and try to get this resolved. > > Cheers, > Leif > > On Tue, Jun 15, 2010 at 10:25 PM, Javier Muguruza > <jav...@at...> wrote: > > Hi, is there anything else we could try? Using a newer version of > wrapper or anything? > > > > Thanks > > javier > > -- > Leif Mortenson > Tanuki Software, Ltd. > 6-16-7-1001 Nishi-Kasai, Edogawa-ku > Tokyo 134-0088 Japan > Tel/Fax: +81-3-3878-3211 > http://www.tanukisoftware.com > lei...@ta... > > ----------------------------------------------------------------------- > ------- > 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 |
|
From: Leif M. <lei...@ta...> - 2010-06-15 14:57:48
|
Javier, Sorry for the delay getting back to you. We reviewed your wrapper.conf files and there are a few things I would like to ask you to try out. 1) The configured wrapper.log file location depends on an environment variable. wrapper.logfile=E:\ADAM\adam/runtime/logs/%ADAM_PROCESS_NAME%.service.log.ROLLNUM That is being set in the parent configuration file, so it should be fine, but could you please try a simple logfile like the following: wrapper.logfile=C:¥TEMP¥wrapper.log Where that directory is known to exist. I would like to see if you get a configuration file in this case. 2) Could you please try downloading the wrapper distribution and then installing the default TestWrapper application as a service to see what happens? If that is having the same problem then we know that it is not something to do with your configuration. 3) You have the following property configured, but I do not see where you are defining ADAM_RUNTIME wrapper.java.additional.4=-XX:HeapDumpPath=%ADAM_RUNTIME%/logs If that did not exist then it might cause the JVM to fail to start. But You should be seeing a wrapper.log with other output long before the JVM is launched. You asked about a newer version of the Wrapper. What version are you using? I am not aware of anything in a newer version that would correct what you are seeing. I am still quite puzzled as to why the Wrapper32 bit version is working but the Wrapper64 bit version is not. The fact that the Wrapper 64-bit works when running as the Administrator user proves that the Wrapper binary itself is fine and that the configuration is correct. The only differences left are permissions, and environment differences. I am not aware of any permission configurations which would prevent a 64-bit program from running, but allow a 32-bit program. Please let me know the results of 1-3 above. If they all fail, lets set up a phone or Skype meeting to walk through what could be happening and try to get this resolved. Cheers, Leif On Tue, Jun 15, 2010 at 10:25 PM, Javier Muguruza <jav...@at...> wrote: > Hi, is there anything else we could try? Using a newer version of wrapper or anything? > > Thanks > javier -- Leif Mortenson Tanuki Software, Ltd. 6-16-7-1001 Nishi-Kasai, Edogawa-ku Tokyo 134-0088 Japan Tel/Fax: +81-3-3878-3211 http://www.tanukisoftware.com lei...@ta... |
|
From: Javier M. <jav...@at...> - 2010-06-15 13:24:25
|
Hi, is there anything else we could try? Using a newer version of wrapper or anything? Thanks javier |
|
From: Leif M. <lei...@ta...> - 2010-06-14 07:14:03
|
Peter, Yes and No. Yes, because you can use the status bar feature of Java 6 to do exactly what you want when the Service is installed with the wrapper.ntservice.interactive=TRUE property set. http://wrapper.tanukisoftware.org/doc/english/prop-ntservice-interactive.html No, because starting with Windows Vista and 2008, Microsoft no longer allows Services to interact directly with the desktop. We are working on a way to work around this so I would appreciate hearing any feedback on exactly what it is that you need to be able to do with the status icon. Cheers, Leif On Mon, Jun 14, 2010 at 3:48 PM, Peter Dahm <pd...@it...> wrote: > Hi, > > > > I’m new to java service wrapper and we check this tool to integrate in our > project. > > > > Is it possible to integrate the tool in an application that needed a gui ? I > would like to have a icon in the windows toolbar to start the gui component > of my application/service > > > > Regards > > > > Peter |
|
From: Peter D. <pd...@it...> - 2010-06-14 06:54:01
|
Hi, I'm new to java service wrapper and we check this tool to integrate in our project. Is it possible to integrate the tool in an application that needed a gui ? I would like to have a icon in the windows toolbar to start the gui component of my application/service Regards Peter |
|
From: Leland, R. <rob...@io...> - 2010-06-11 16:52:43
|
Packet length was only for the SYSLOG-NG implementation over TCP. So you are safe with the UDP spec, especially since you are only writing the client. If you can test with two different SYSLOG servers/daemons you should be pretty safe. When I mentioned SYSLOG-NG(TCP) Implementations creating compound SYSLOG entries: In that scenario the SYSLOG entry message would go into a work/message QUE. Then the Worker QUE can decide to send two or more separate SYSLOG entries from two different applications to the SYSLOG-NG server in the same TCP transaction. This confused some SYSLOG servers and resulted in two separate SYSLOG entries being grouped together. Again since you are only writing the UDP SYSLOG client your do not have to concerned with that. -----Original Message----- From: Leif Mortenson [mailto:lei...@ta...] Sent: Thursday, June 10, 2010 1:49 AM To: wra...@li... Subject: Re: [Wrapper-user] wrapper with syslog host Rob, Thank you for the feedback. I think we are set then with the implemented UDP based syslog implementation. It will be released in 3.5.0 at the end of June. The specification that we implemented to places a maximum packet size of 1024 bytes including all headers. When viewed in the syslog output on a linux server, it looks like this for a very long line. The following output was a test of a 200 byte packet length. We add "..." to the beginning and end of long wrapped lines and trim them exactly to the max packet length: --- Jun 9 04:18:26 io-2.local io testwrapper: jvm 1 : sun.boot.class.path=/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jsfd.jar:/System/Library/Frameworks/JavaVM.framework/Versions/... Jun 9 04:18:26 io-2.local io testwrapper: jvm 1 : ...1.5.0/Classes/classes.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/ui.jar:/System/Library/Frameworks/JavaVM.framework/... Jun 9 04:18:26 io-2.local io testwrapper: jvm 1 : ...Versions/1.5.0/Classes/laf.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/sunrsasign.jar:/System/Library/Frameworks/Java... Jun 9 04:18:26 io-2.local io testwrapper: jvm 1 : ...VM.framework/Versions/1.5.0/Classes/jsse.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jce.jar:/System/Library/Framewor... Jun 9 04:18:26 io-2.local io testwrapper: jvm 1 : ...ks/JavaVM.framework/Versions/1.5.0/Classes/charsets.jar --- We are not planning on making the packet length configurable as the specification is pretty clear. Let me know what you think. It is actually easy to make it configurable. But allowing it to be so could cause problems on the log servers or relays. Cheers, Leif On Wed, Jun 9, 2010 at 5:54 AM, Leland, Robert <rob...@io...> wrote: > My experience is as a user of several SYSLOG-NG implementation not as an implementer. Unless it is a much requested feature I would stay away from a TCP client implementation, and I have experience varying incompatibilities of servers as to how they handle things. This has resulted in Dropped logs(even in TCP), truncated logs, and multiple/compound log entries in one SYSLOG database entry. > > Even though SYSLOG is over TCP the, and a message length is in the TCP header, the SYSLOG-NG v2 protocol did not have a concept of message length and still depended on message delimiters. > I believe SYSLOG-NG V3 which is based on http://tools.ietf.org/html/rfc5424, was scheduled to make use of a message length to make implementing the Client and Server more standard. > > > This is off topic but..... > My experience is that some applications misuse SYSLOG for non events, that is better served with a application auditing. The things I look for that usually rules out SYSLOG usage (TCP or UDP) are: > Large message Size > 4K (1K). > The application wants to send a complex payload such as XML. > The desire to run real time metrics against the SYSLOG server for reports over log time periods. > The SYSLOG servers I have seen store the SYSLOG into a generic database which make sense. > To produce a report each log entry has to be first filtered by time or some other generic criteria, then parsed into an intermediated database table(s) that then is sent to a reporting tool such as Crystal Reports or OBIEE. Each time a report is generated the same process is repeated. Many SYSLOG implementations do not optimize their use of memory and choke when generating reports over long time periods(several months). Just some things to consider > > -Rob > > -----Original Message----- > From: Leif Mortenson [mailto:lei...@ta...] > Sent: Tuesday, June 08, 2010 4:03 PM > To: wra...@li... > Subject: Re: [Wrapper-user] wrapper with syslog host > > Robert, > Thank you for the extra info. I got a UDP based syslog target working > that is based on RFC3164 (http://www.ietf.org/rfc/rfc3164.txt) It > limits the message length to 1024 characters. Lines that are longer > than that will be wrapper into multiple packets. > > It still needs a lot of testing, but we will have this in the 3.5.0 > release due out by the end of June. > > Will this be sufficient? TCP based logging would be a bit more > difficult to handle because of the possibility that the outgoing > packets could block. > > Cheers, > Leif > > On Wed, Jun 9, 2010 at 3:37 AM, Leland, Robert <rob...@io...> wrote: >> It might be helpful to be specific as to the type of SYSLOG server >> support is desired. >> >> The UDP based SYSLOG is easiest to support since there is a standard. >> >> As far as the TCP SYSLOG it's been 18 months worked with that and then >> there was no SYSLOG standard over Connected TCP networks. The closest to >> that is a open source/commercial product that others seem to follow. >> The SYSLOG-TCP or SYSLOG-NG servers that exist all behave very >> differently. >> Since the pseudo standard was based on the UDP version 18 months ago >> most if not all still had a message size limit that varies from 1K to 4K >> depending on the implementation. They also vary on how they piece >> together messages. >> >> >> -----Original Message----- >> From: Leif Mortenson [mailto:lei...@ta...] >> Sent: Tuesday, June 08, 2010 11:51 AM >> To: wra...@li... >> Subject: Re: [Wrapper-user] wrapper with syslog host >> >> Gerald, >> Sorry for the delay on this. We were investigating what is possible >> at an OS level as well as the possibility of sending the remote syslog >> messages directly. The Wrapper does not currently support this. >> Please confirm that you are wanting to send the Wrapper's output to a >> remote syslog server directly, and not all of the syslog activity on >> the server. >> >> Cheers, >> Leif >> >> On Sat, Jun 5, 2010 at 12:09 AM, Gerald Schnabel >> <ger...@gm...> wrote: >>> hi, >>> I am using a syslog server, which is running on a separate machine. >> Most applications I use are configured with log4j >>> where I can use a syslog appender with the parameter SyslogHost. >>> But for the java service wrapper I can just find the properties >>> >>> wrapper.syslog.facility >>> wrapper.syslog.ident >>> wrapper.syslog.loglevel >>> >>> How can I configure the java service wrapper for using the syslog >> server? >>> >>> Thanks in advance, >>> Gerald ------------------------------------------------------------------------------ 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 |
|
From: Thomas S. <Tho...@ra...> - 2010-06-11 11:28:37
|
<font size=2 face="sans-serif">Does anyone know how to turn on the digest setting for this list?</font> |
|
From: Javier M. <jav...@at...> - 2010-06-11 10:47:42
|
This email contained a .zip file attachment. Raytheon does not allow email attachments that are considered likely to contain malicious code. For your protection this attachment has been removed. If this email is from an unknown source, please simply delete this email. If this email was expected, and it is from a known sender, you may follow the below suggested instructions to obtain these types of attachments. + Instruct the sender to enclose the file(s) in a ".zip" compressed file, and rename the ".zip" compressed file with a different extension, such as, ".rtnzip". Password protecting the renamed ".zip" compressed file adds an additional layer of protection. When you receive the file, please rename it with the extension ".zip". Additional instructions and options on how to receive these attachments can be found at: http://security.it.ray.com/antivirus/extensions.html http://security.it.ray.com/news/2007/zipfiles.html Should you have any questions or difficulty with these instructions, please contact the Help Desk at 877.844.4712 --- > -----Original Message----- > From: Leif Mortenson [mailto:lei...@ta...] > Sent: viernes, 11 de junio de 2010 11:58 > To: wra...@li... > Subject: Re: [Wrapper-user] Antw: service not starting on Windows > 2008R1 64b > > 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] correct > > > [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] attached, it's three files with includes, see ManagerProcess.conf, I didn't include the license file > > > [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] yes > > > [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 > > ----------------------------------------------------------------------- > ------- > 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 |
|
From: Javier M. <jav...@at...> - 2010-06-11 10:29:52
|
> -----Original Message-----
> From: Leif Mortenson [mailto:lei...@ta...]
> Sent: viernes, 11 de junio de 2010 11:58
> To: wra...@li...
> Subject: Re: [Wrapper-user] Antw: service not starting on Windows
> 2008R1 64b
>
> 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] correct
>
> > [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] attached, it's three files with includes, see ManagerProcess.conf, I didn't include the license file
>
> > [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] yes
>
> > [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
>
> -----------------------------------------------------------------------
> -------
> 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
|
|
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
|
|
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
|
|
From: Leif M. <lei...@ta...> - 2010-06-11 08:39:03
|
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
|
|
From: Hubert F. <Hub...@ab...> - 2010-06-11 08:18:14
|
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
------------------------------------------------------------------------------
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
|
|
From: Leif M. <lei...@ta...> - 2010-06-11 08:00:28
|
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?
I should have asked you a long time ago, but would it be possible for
you send me your wrapper.conf file?
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
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.
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
|
|
From: Javier M. <jav...@at...> - 2010-06-11 07:40:27
|
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
|
|
From: Leif M. <lei...@ta...> - 2010-06-10 14:17:28
|
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? 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. 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. 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. 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. Cheers, Leif On Thu, Jun 10, 2010 at 10:09 PM, Javier Muguruza <jav...@at...> wrote: > A further info I got from a colleague, he tested the exact environment in a windows 2003 enterprise x64 R2 SP2 and it worked fine, so the problem is in Windows 2008 64b > >> -----Original Message----- >> From: Javier Muguruza [mailto:jav...@at...] >> Sent: jueves, 10 de junio de 2010 11:02 >> To: wra...@li... >> Subject: Re: [Wrapper-user] Antw: service not starting on Windows >> 2008R1 64b >> >> Leif, >> >> Yes we have verified all these, all are ok for SYSTEM. I agree with you >> that it looks like a permission issue cause it runs fine with >> Administrator. But OTOH this exact setup works if we change to a 32b >> jdk and we use 32b wrapper...maybe the issue is permission in some file >> only involved in 64b jdk... >> >> Thanks, >> javier >> >> > -----Original Message----- >> > From: Leif Mortenson [mailto:lei...@ta...] >> > Sent: jueves, 10 de junio de 2010 10:38 >> > To: wra...@li... >> > Subject: Re: [Wrapper-user] Antw: service not starting on Windows >> > 2008R1 64b >> > >> > Javier, >> > Thank you for that information. If the wrapper.log is never being >> > written then that most likely means that the Windows Service Manager >> > is failing to ever launch the wrapper.exe binary as a service. This >> > can happen if the SYSTEM user does not have access to the directory >> > where the Wrapper.exe binary is located. Could you please check the >> > file permissions on all of the parent directories as well and make >> > sure that they have at least read access for the SYSTEM user? The >> > logs directory will also need to have write access. >> > >> > Cheers, >> > Leif >> > >> > On Thu, Jun 10, 2010 at 5:30 PM, Javier Muguruza >> > <jav...@at...> wrote: >> > > Replays to both of you guys inline, thanks: >> > > >> > > >> > > >> > > Hi, >> > > >> > > How does it fail, on what point does it fail? Windows Service >> cannot >> > be >> > > started, it is working on the same environment with a x86 jdk (and >> > > wrapper-windows-x86-32-3.3.0) using the same config, and Path to >> > executable >> > > Path to executable: C:\ADAM\adam\wrapper-bin\wrapper.exe -s >> > > C:\ADAM\adam\wrapper-conf\ManagerProcess.conf >> > > >> > > If launched directly through a command line like >> > > C:\ADAM\adam\wrapper-bin\wrapper.exe >> > > C:\ADAM\adam\wrapper-conf\ManagerProcess.conf it starts properly >> > > >> > > Do you have Wrapper Debug Settings enabled to generate verbose >> > output? >> > > >> > > Do you use network resources like mapped drives or unc path? No, >> > everything >> > > is on local drive, no mapped drive >> > > >> > > Do you use any resource that is only available to "regular" windows >> > > >> > > users like printers? No >> > > >> > > Do you try access a regular windows users environment? We try to >> > access a >> > > few environment variables, but they are all available globally. >> > > >> > > Hubert >> > > >> > > >> > > >> > > Christian. >> > > >> > > >> > > >> > > >> > > >> > > you can send support requests over this mailing list as well as >> > > >> > > directly sending to su...@ta... >> > > >> > > >> > > >> > > Hubert already pointed you to possible problems when starting as a >> > service. >> > > >> > > >> > > >> > > Let me add some additional questions: >> > > >> > > If the wrapper fails to start as service with the local system >> user, >> > > >> > > could you check if there is a log file "wrapper.log" in the folder >> > the >> > > >> > > wrapper binary is located? >> > > >> > > No wrapper.log file is left on the bin folder. >> > > >> > > >> > > >> > > Could you also try to start the service from Console (you need to >> > > >> > > start the console as admin) and run the Start<App>.bat file? What >> > > >> > > output message from the wrapper can you see there? >> > > >> > > It also fails, >> > > >> > > C:\ADAM\adam\wrapper-bin>StartTestWrapper-NT.bat >> > > ..\wrapper-conf\ManagerProcess. >> > > >> > > conf >> > > >> > > wrapper | Working directory set to: C:\ADAM\adam\mig-master >> > > >> > > wrapper | Starting the adam-ManagerProcess service... >> > > >> > > wrapper | Waiting to start... >> > > >> > > wrapper | The adam-ManagerProcess service was launched, but failed >> > to >> > > start. >> > > >> > > Press any key to continue . . . >> > > >> > > >> > > >> > > Launching directly the wrapper.exe it works >> > > >> > > C:\ADAM\adam\wrapper-bin>wrapper.exe ..\wrapper- >> > conf\ManagerProcess.conf >> > > >> > > wrapper | Working directory set to: C:\ADAM\adam\mig-master >> > > >> > > wrapper | --> Wrapper Started as Console >> > > >> > > wrapper | Java Service Wrapper Standard Edition 3.3.0 >> > > >> > > wrapper | Copyright (C) 1999-2008 Tanuki Software, Inc. All >> > Rights >> > > Reserved. >> > > >> > > >> > > >> > > wrapper | http://wrapper.tanukisoftware.org >> > > >> > > wrapper | Licensed to Atempo Java Service Wrapper for ADAM >> Manager >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > Sincerely, >> > > >> > > Christian |
|
From: Javier M. <jav...@at...> - 2010-06-10 13:08:21
|
A further info I got from a colleague, he tested the exact environment in a windows 2003 enterprise x64 R2 SP2 and it worked fine, so the problem is in Windows 2008 64b > -----Original Message----- > From: Javier Muguruza [mailto:jav...@at...] > Sent: jueves, 10 de junio de 2010 11:02 > To: wra...@li... > Subject: Re: [Wrapper-user] Antw: service not starting on Windows > 2008R1 64b > > Leif, > > Yes we have verified all these, all are ok for SYSTEM. I agree with you > that it looks like a permission issue cause it runs fine with > Administrator. But OTOH this exact setup works if we change to a 32b > jdk and we use 32b wrapper...maybe the issue is permission in some file > only involved in 64b jdk... > > Thanks, > javier > > > -----Original Message----- > > From: Leif Mortenson [mailto:lei...@ta...] > > Sent: jueves, 10 de junio de 2010 10:38 > > To: wra...@li... > > Subject: Re: [Wrapper-user] Antw: service not starting on Windows > > 2008R1 64b > > > > Javier, > > Thank you for that information. If the wrapper.log is never being > > written then that most likely means that the Windows Service Manager > > is failing to ever launch the wrapper.exe binary as a service. This > > can happen if the SYSTEM user does not have access to the directory > > where the Wrapper.exe binary is located. Could you please check the > > file permissions on all of the parent directories as well and make > > sure that they have at least read access for the SYSTEM user? The > > logs directory will also need to have write access. > > > > Cheers, > > Leif > > > > On Thu, Jun 10, 2010 at 5:30 PM, Javier Muguruza > > <jav...@at...> wrote: > > > Replays to both of you guys inline, thanks: > > > > > > > > > > > > Hi, > > > > > > How does it fail, on what point does it fail? Windows Service > cannot > > be > > > started, it is working on the same environment with a x86 jdk (and > > > wrapper-windows-x86-32-3.3.0) using the same config, and Path to > > executable > > > Path to executable: C:\ADAM\adam\wrapper-bin\wrapper.exe -s > > > C:\ADAM\adam\wrapper-conf\ManagerProcess.conf > > > > > > If launched directly through a command line like > > > C:\ADAM\adam\wrapper-bin\wrapper.exe > > > C:\ADAM\adam\wrapper-conf\ManagerProcess.conf it starts properly > > > > > > Do you have Wrapper Debug Settings enabled to generate verbose > > output? > > > > > > Do you use network resources like mapped drives or unc path? No, > > everything > > > is on local drive, no mapped drive > > > > > > Do you use any resource that is only available to "regular" windows > > > > > > users like printers? No > > > > > > Do you try access a regular windows users environment? We try to > > access a > > > few environment variables, but they are all available globally. > > > > > > Hubert > > > > > > > > > > > > Christian. > > > > > > > > > > > > > > > > > > you can send support requests over this mailing list as well as > > > > > > directly sending to su...@ta... > > > > > > > > > > > > Hubert already pointed you to possible problems when starting as a > > service. > > > > > > > > > > > > Let me add some additional questions: > > > > > > If the wrapper fails to start as service with the local system > user, > > > > > > could you check if there is a log file "wrapper.log" in the folder > > the > > > > > > wrapper binary is located? > > > > > > No wrapper.log file is left on the bin folder. > > > > > > > > > > > > Could you also try to start the service from Console (you need to > > > > > > start the console as admin) and run the Start<App>.bat file? What > > > > > > output message from the wrapper can you see there? > > > > > > It also fails, > > > > > > C:\ADAM\adam\wrapper-bin>StartTestWrapper-NT.bat > > > ..\wrapper-conf\ManagerProcess. > > > > > > conf > > > > > > wrapper | Working directory set to: C:\ADAM\adam\mig-master > > > > > > wrapper | Starting the adam-ManagerProcess service... > > > > > > wrapper | Waiting to start... > > > > > > wrapper | The adam-ManagerProcess service was launched, but failed > > to > > > start. > > > > > > Press any key to continue . . . > > > > > > > > > > > > Launching directly the wrapper.exe it works > > > > > > C:\ADAM\adam\wrapper-bin>wrapper.exe ..\wrapper- > > conf\ManagerProcess.conf > > > > > > wrapper | Working directory set to: C:\ADAM\adam\mig-master > > > > > > wrapper | --> Wrapper Started as Console > > > > > > wrapper | Java Service Wrapper Standard Edition 3.3.0 > > > > > > wrapper | Copyright (C) 1999-2008 Tanuki Software, Inc. All > > Rights > > > Reserved. > > > > > > > > > > > > wrapper | http://wrapper.tanukisoftware.org > > > > > > wrapper | Licensed to Atempo Java Service Wrapper for ADAM > Manager > > > > > > > > > > > > > > > > > > > > > > > > Sincerely, > > > > > > Christian > > > > > > > --------------------------------------------------------------------- > -- > > ------- > > 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 > > ----------------------------------------------------------------------- > ------- > 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 |
|
From: Javier M. <jav...@at...> - 2010-06-10 09:01:17
|
Leif, Yes we have verified all these, all are ok for SYSTEM. I agree with you that it looks like a permission issue cause it runs fine with Administrator. But OTOH this exact setup works if we change to a 32b jdk and we use 32b wrapper...maybe the issue is permission in some file only involved in 64b jdk... Thanks, javier > -----Original Message----- > From: Leif Mortenson [mailto:lei...@ta...] > Sent: jueves, 10 de junio de 2010 10:38 > To: wra...@li... > Subject: Re: [Wrapper-user] Antw: service not starting on Windows > 2008R1 64b > > Javier, > Thank you for that information. If the wrapper.log is never being > written then that most likely means that the Windows Service Manager > is failing to ever launch the wrapper.exe binary as a service. This > can happen if the SYSTEM user does not have access to the directory > where the Wrapper.exe binary is located. Could you please check the > file permissions on all of the parent directories as well and make > sure that they have at least read access for the SYSTEM user? The > logs directory will also need to have write access. > > Cheers, > Leif > > On Thu, Jun 10, 2010 at 5:30 PM, Javier Muguruza > <jav...@at...> wrote: > > Replays to both of you guys inline, thanks: > > > > > > > > Hi, > > > > How does it fail, on what point does it fail? Windows Service cannot > be > > started, it is working on the same environment with a x86 jdk (and > > wrapper-windows-x86-32-3.3.0) using the same config, and Path to > executable > > Path to executable: C:\ADAM\adam\wrapper-bin\wrapper.exe -s > > C:\ADAM\adam\wrapper-conf\ManagerProcess.conf > > > > If launched directly through a command line like > > C:\ADAM\adam\wrapper-bin\wrapper.exe > > C:\ADAM\adam\wrapper-conf\ManagerProcess.conf it starts properly > > > > Do you have Wrapper Debug Settings enabled to generate verbose > output? > > > > Do you use network resources like mapped drives or unc path? No, > everything > > is on local drive, no mapped drive > > > > Do you use any resource that is only available to "regular" windows > > > > users like printers? No > > > > Do you try access a regular windows users environment? We try to > access a > > few environment variables, but they are all available globally. > > > > Hubert > > > > > > > > Christian. > > > > > > > > > > > > you can send support requests over this mailing list as well as > > > > directly sending to su...@ta... > > > > > > > > Hubert already pointed you to possible problems when starting as a > service. > > > > > > > > Let me add some additional questions: > > > > If the wrapper fails to start as service with the local system user, > > > > could you check if there is a log file "wrapper.log" in the folder > the > > > > wrapper binary is located? > > > > No wrapper.log file is left on the bin folder. > > > > > > > > Could you also try to start the service from Console (you need to > > > > start the console as admin) and run the Start<App>.bat file? What > > > > output message from the wrapper can you see there? > > > > It also fails, > > > > C:\ADAM\adam\wrapper-bin>StartTestWrapper-NT.bat > > ..\wrapper-conf\ManagerProcess. > > > > conf > > > > wrapper | Working directory set to: C:\ADAM\adam\mig-master > > > > wrapper | Starting the adam-ManagerProcess service... > > > > wrapper | Waiting to start... > > > > wrapper | The adam-ManagerProcess service was launched, but failed > to > > start. > > > > Press any key to continue . . . > > > > > > > > Launching directly the wrapper.exe it works > > > > C:\ADAM\adam\wrapper-bin>wrapper.exe ..\wrapper- > conf\ManagerProcess.conf > > > > wrapper | Working directory set to: C:\ADAM\adam\mig-master > > > > wrapper | --> Wrapper Started as Console > > > > wrapper | Java Service Wrapper Standard Edition 3.3.0 > > > > wrapper | Copyright (C) 1999-2008 Tanuki Software, Inc. All > Rights > > Reserved. > > > > > > > > wrapper | http://wrapper.tanukisoftware.org > > > > wrapper | Licensed to Atempo Java Service Wrapper for ADAM Manager > > > > > > > > > > > > > > > > Sincerely, > > > > Christian > > > > ----------------------------------------------------------------------- > ------- > 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 |