wrapper-user — User issues for Wrapper. (Support questions, etc.)

[Wrapper-user] Error loading lib under 32 bit hp/ux

[Annam, S. <sun...@ea...>]

Leif,

As I mentioned in my previous mail, I figured out what I was missing and
executed myApps.myApps1 script.

Now the next issue is with HP-UX.

I am getting message that=20
'libwrapper.so' could not be located in the following java.library.path:

I went through all the postings related to 'Error loading lib under
hp/ux' from 64-bit HP-UX users.
We have 32 bit HP-UX but still we have same issue.
In one of the postings, I found libwrapper.so for 32-bit libwrapper.sl
for 64 bit. Why different extensions?=20
We have some other applications that use a native library and the
library name has 'sl' extension. Am I missing something?

Thanks in advance.

Sunil


-----Original Message-----
From: wra...@li...
[mailto:wra...@li...] On Behalf Of Leif
Mortenson
Sent: Wednesday, May 26, 2004 5:00 PM
To: wra...@li...
Subject: Re: [Wrapper-user] what command to execute

Annam, Sunil wrote:

> I have an application myApps1 in a package myApps. Right now I use=20
> 'java myApps.myApps1' on command prompt to execute my application.
>
> I went through Wrapper documentation and JBoss example. I also created

> similar directory structure and conf file for my application.
>
> Now what should I do? I mean what command to execute on command
prompt.
>
The integration tutorial should have had you create 3 batch files for=20
Windows, or a
shell script for UNIX platforms.

Running them will launch the Wrapper and your program. Is that what you=20
are asking?

Cheers,
Leif



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.

Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

RE: [Wrapper-user] does wrapper depend on JAVA_HOME?

[Cocalea, E. <Co...@sy...>]

Hi,

Version was 3.0.5. With 3.1.0, set.JAVA_HOME works and the wrapper
successfuly starts and problem solved.

Thanks a lot.

/EC

-----Original Message-----
From: Leif Mortenson [mailto:le...@ta...] 
Sent: Thursday, May 27, 2004 3:47 PM
To: wra...@li...
Subject: Re: [Wrapper-user] does wrapper depend on JAVA_HOME?

I am wondering if that is a fairly old version of the Wrapper. Could you
try downloading 3.1.0 and replacing Wrapper.exe, Wrapper.dll and
wrapper.jar for kicks.

If the JAVA_HOME variable was not being expanded correctly, you
should still be seeing the '%' characters...

Were did you get the version you are using? The Wrapper will display
its own version on startup. But right now, that message comes from
the java classes rather than the wrapper binary so it is not possible
to see what it is if the JVM is not being launched correctly...
(Something I should probably change for a future version.)

Try hard coding the JVM location and running the program once.
You should see a banner right after the JVM is launched that looks
like this:

wrapper | Launching a JVM...
jvm 1 | Initializing...
jvm 1 | Wrapper (Version 3.1.0) http://wrapper.tanukisoftware.org

or

wrapper | Launching a JVM...
jvm 1 | Initializing...
jvm 1 | Wrapper (Version 3.0.5)

, depending on the version.

Cheers,
Leif

Cocalea, Eugen wrote:

>I have the following in wrapper.conf:
>
>set.JAVA_HOME=c:/j2sdk1.4.2_03
>wrapper.java.command=%JAVA_HOME%/bin/java
>
>the error I get is:
>
>e:\>wrapper -c wrapper.conf
>wrapper  | --> Wrapper Started as Console
>wrapperp | server listening on port 1778.
>wrapper  | Launching a JVM...
>wrapper  | command: "JAVA_HOME/bin/java"
>wrapper  | can not execute ""JAVA_HOME/bin/java"" (ERR=2)
>wrapper  | Critical error: wait for JVM process failed
>
>So it seems that indeed the variable doesn't get expanded. No spaces around
>the '=' sign.
>
>Anyway, if JAVA_HOME is defined outside the wrapper.conf (not in the
command
>line), it gets expanded.
>
>I don't know what version I use :) Is there a way to find this out?
>
>/EC
>
>-----Original Message-----
>From: Leif Mortenson [mailto:le...@ta...] 
>Sent: Thursday, May 27, 2004 3:19 PM
>To: wra...@li...
>Subject: Re: [Wrapper-user] does wrapper depend on JAVA_HOME?
>
>Try running the Wrapper with wrapper.debug=true set in your wrapper.conf
>file. This will cause the full command used to launch java to be logged.
>This should hep you to narrow down the problem.
>
>If you see something like %JAVA_HOME%, unexpanded in the generated
>command, than means that the environment variable is not being registered
>correctly.
>
>What Wrapper version are you using. 3.1.0 handles spaces around the '='
>in property declarations correctly, but the properties are not recognized
in
>earlier versions if the spaces are there.
>
>
>Cheers,
>Leif
>
>Cocalea, Eugen wrote:
>
>  
>
>>Hi,
>>
>>Unfortunately, it seems that (in my case),
>>    
>>
>set.JAVA_HOME=<path_to_java_home>
>  
>
>>doesn't work. I don't know why.
>>
>>I tried both setting it in wrapper.conf and supplying it in the command
>>line, like:
>>
>>wrapper -c wrapper.conf "set.JAVA_HOME=<path_to_java_home>"
>>
>>In both cases, with
>>
>>wrapper.java.command = %JAVA_HOME%/bin/java
>>
>>the wrapper complains that it cannot execute the command.
>>
>>/EC
>>
>>-----Original Message-----
>>From: Leif Mortenson [mailto:le...@ta...] 
>>Sent: Wednesday, May 26, 2004 10:11 AM
>>To: wra...@li...
>>Subject: Re: [Wrapper-user] does wrapper depend on JAVA_HOME?
>>
>>Eugen,
>>The Wrapper does not do anything with the JAVA_HOME environment
>>variable. As long as you are not referencing it in your wrapper.conf file
>>then there is also no way for the application running the JVM to reference
>>it.
>>JAVA_HOME is usually passed to the JVM using a system property like:
>>
>>-Djavahome=%JAVA_HOME%
>>
>>It is perfectly safe to do the following:
>>wrapper.java.command=../jre/bin/java
>>
>>One option is to define the JAVA_HOME environment variable within
>>your wrapper.conf file as follows:
>>
>>set.JAVA_HOME=../jre
>>wrapper.java.command=%JAVA_HOME%/bin/java
>>
>>This has the benefit of making it easy to reference the JRE location
>>throughout your wrapper.conf file. The user can also use a system
>>value by simply commenting out the set line.
>>
>>Cheers,
>>Leif
>>
>>
>>
>>Cocalea, Eugen wrote:
>>
>> 
>>
>>    
>>
>>>Hello,
>>>
>>>This is a bit tricky, because not even me know what the question is
about.
>>>
>>>I have a java application that I want to run as a windows service and
>>>I use wrapper to do this.
>>>
>>>My app wrapper.conf used to have
>>>
>>>wrapper.java.command=%JAVA_HOME%/bin/java
>>>
>>>The problem is that I have to run different versions of the
>>>application, that are certified against different JREs.
>>>
>>>So, my question is: if I hardcode the path to the JRE I need in
>>>wrapper.java.command, do I need to check anything else to see if the
>>>application really uses that JRE?
>>>
>>>Example:
>>>
>>>- JAVA_HOME points to JRE 1.3
>>>
>>>- I need to run the app with JRE 1.4
>>>
>>>- wrapper.java.command is <JRE1.4_install_path>/bin/java
>>>
>>>I should be safe, correct? *_Assuming my application doesn't use
>>>JAVA_HOME._*
>>>
>>>   
>>>
>>>      
>>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: Oracle 10g
>>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>>Take an Oracle 10g class now, and we'll give you the exam FREE.
>>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>>_______________________________________________
>>Wrapper-user mailing list
>>Wra...@li...
>>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: Oracle 10g
>>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>>Take an Oracle 10g class now, and we'll give you the exam FREE.
>>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>>_______________________________________________
>>Wrapper-user mailing list
>>Wra...@li...
>>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>> 
>>
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] does wrapper depend on JAVA_HOME?

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

I am wondering if that is a fairly old version of the Wrapper. Could you
try downloading 3.1.0 and replacing Wrapper.exe, Wrapper.dll and
wrapper.jar for kicks.

If the JAVA_HOME variable was not being expanded correctly, you
should still be seeing the '%' characters...

Were did you get the version you are using? The Wrapper will display
its own version on startup. But right now, that message comes from
the java classes rather than the wrapper binary so it is not possible
to see what it is if the JVM is not being launched correctly...
(Something I should probably change for a future version.)

Try hard coding the JVM location and running the program once.
You should see a banner right after the JVM is launched that looks
like this:

wrapper | Launching a JVM...
jvm 1 | Initializing...
jvm 1 | Wrapper (Version 3.1.0) http://wrapper.tanukisoftware.org

or

wrapper | Launching a JVM...
jvm 1 | Initializing...
jvm 1 | Wrapper (Version 3.0.5)

, depending on the version.

Cheers,
Leif

Cocalea, Eugen wrote:

>I have the following in wrapper.conf:
>
>set.JAVA_HOME=c:/j2sdk1.4.2_03
>wrapper.java.command=%JAVA_HOME%/bin/java
>
>the error I get is:
>
>e:\>wrapper -c wrapper.conf
>wrapper  | --> Wrapper Started as Console
>wrapperp | server listening on port 1778.
>wrapper  | Launching a JVM...
>wrapper  | command: "JAVA_HOME/bin/java"
>wrapper  | can not execute ""JAVA_HOME/bin/java"" (ERR=2)
>wrapper  | Critical error: wait for JVM process failed
>
>So it seems that indeed the variable doesn't get expanded. No spaces around
>the '=' sign.
>
>Anyway, if JAVA_HOME is defined outside the wrapper.conf (not in the command
>line), it gets expanded.
>
>I don't know what version I use :) Is there a way to find this out?
>
>/EC
>
>-----Original Message-----
>From: Leif Mortenson [mailto:le...@ta...] 
>Sent: Thursday, May 27, 2004 3:19 PM
>To: wra...@li...
>Subject: Re: [Wrapper-user] does wrapper depend on JAVA_HOME?
>
>Try running the Wrapper with wrapper.debug=true set in your wrapper.conf
>file. This will cause the full command used to launch java to be logged.
>This should hep you to narrow down the problem.
>
>If you see something like %JAVA_HOME%, unexpanded in the generated
>command, than means that the environment variable is not being registered
>correctly.
>
>What Wrapper version are you using. 3.1.0 handles spaces around the '='
>in property declarations correctly, but the properties are not recognized in
>earlier versions if the spaces are there.
>
>
>Cheers,
>Leif
>
>Cocalea, Eugen wrote:
>
>  
>
>>Hi,
>>
>>Unfortunately, it seems that (in my case),
>>    
>>
>set.JAVA_HOME=<path_to_java_home>
>  
>
>>doesn't work. I don't know why.
>>
>>I tried both setting it in wrapper.conf and supplying it in the command
>>line, like:
>>
>>wrapper -c wrapper.conf "set.JAVA_HOME=<path_to_java_home>"
>>
>>In both cases, with
>>
>>wrapper.java.command = %JAVA_HOME%/bin/java
>>
>>the wrapper complains that it cannot execute the command.
>>
>>/EC
>>
>>-----Original Message-----
>>From: Leif Mortenson [mailto:le...@ta...] 
>>Sent: Wednesday, May 26, 2004 10:11 AM
>>To: wra...@li...
>>Subject: Re: [Wrapper-user] does wrapper depend on JAVA_HOME?
>>
>>Eugen,
>>The Wrapper does not do anything with the JAVA_HOME environment
>>variable. As long as you are not referencing it in your wrapper.conf file
>>then there is also no way for the application running the JVM to reference
>>it.
>>JAVA_HOME is usually passed to the JVM using a system property like:
>>
>>-Djavahome=%JAVA_HOME%
>>
>>It is perfectly safe to do the following:
>>wrapper.java.command=../jre/bin/java
>>
>>One option is to define the JAVA_HOME environment variable within
>>your wrapper.conf file as follows:
>>
>>set.JAVA_HOME=../jre
>>wrapper.java.command=%JAVA_HOME%/bin/java
>>
>>This has the benefit of making it easy to reference the JRE location
>>throughout your wrapper.conf file. The user can also use a system
>>value by simply commenting out the set line.
>>
>>Cheers,
>>Leif
>>
>>
>>
>>Cocalea, Eugen wrote:
>>
>> 
>>
>>    
>>
>>>Hello,
>>>
>>>This is a bit tricky, because not even me know what the question is about.
>>>
>>>I have a java application that I want to run as a windows service and
>>>I use wrapper to do this.
>>>
>>>My app wrapper.conf used to have
>>>
>>>wrapper.java.command=%JAVA_HOME%/bin/java
>>>
>>>The problem is that I have to run different versions of the
>>>application, that are certified against different JREs.
>>>
>>>So, my question is: if I hardcode the path to the JRE I need in
>>>wrapper.java.command, do I need to check anything else to see if the
>>>application really uses that JRE?
>>>
>>>Example:
>>>
>>>- JAVA_HOME points to JRE 1.3
>>>
>>>- I need to run the app with JRE 1.4
>>>
>>>- wrapper.java.command is <JRE1.4_install_path>/bin/java
>>>
>>>I should be safe, correct? *_Assuming my application doesn't use
>>>JAVA_HOME._*
>>>
>>>   
>>>
>>>      
>>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: Oracle 10g
>>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>>Take an Oracle 10g class now, and we'll give you the exam FREE.
>>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>>_______________________________________________
>>Wrapper-user mailing list
>>Wra...@li...
>>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: Oracle 10g
>>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>>Take an Oracle 10g class now, and we'll give you the exam FREE.
>>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>>_______________________________________________
>>Wrapper-user mailing list
>>Wra...@li...
>>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>> 
>>
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>

RE: [Wrapper-user] does wrapper depend on JAVA_HOME?

[Cocalea, E. <Co...@sy...>]

I have the following in wrapper.conf:

set.JAVA_HOME=c:/j2sdk1.4.2_03
wrapper.java.command=%JAVA_HOME%/bin/java

the error I get is:

e:\>wrapper -c wrapper.conf
wrapper  | --> Wrapper Started as Console
wrapperp | server listening on port 1778.
wrapper  | Launching a JVM...
wrapper  | command: "JAVA_HOME/bin/java"
wrapper  | can not execute ""JAVA_HOME/bin/java"" (ERR=2)
wrapper  | Critical error: wait for JVM process failed

So it seems that indeed the variable doesn't get expanded. No spaces around
the '=' sign.

Anyway, if JAVA_HOME is defined outside the wrapper.conf (not in the command
line), it gets expanded.

I don't know what version I use :) Is there a way to find this out?

/EC

-----Original Message-----
From: Leif Mortenson [mailto:le...@ta...] 
Sent: Thursday, May 27, 2004 3:19 PM
To: wra...@li...
Subject: Re: [Wrapper-user] does wrapper depend on JAVA_HOME?

Try running the Wrapper with wrapper.debug=true set in your wrapper.conf
file. This will cause the full command used to launch java to be logged.
This should hep you to narrow down the problem.

If you see something like %JAVA_HOME%, unexpanded in the generated
command, than means that the environment variable is not being registered
correctly.

What Wrapper version are you using. 3.1.0 handles spaces around the '='
in property declarations correctly, but the properties are not recognized in
earlier versions if the spaces are there.


Cheers,
Leif

Cocalea, Eugen wrote:

>Hi,
>
>Unfortunately, it seems that (in my case),
set.JAVA_HOME=<path_to_java_home>
>doesn't work. I don't know why.
>
>I tried both setting it in wrapper.conf and supplying it in the command
>line, like:
>
>wrapper -c wrapper.conf "set.JAVA_HOME=<path_to_java_home>"
>
>In both cases, with
>
>wrapper.java.command = %JAVA_HOME%/bin/java
>
>the wrapper complains that it cannot execute the command.
>
>/EC
>
>-----Original Message-----
>From: Leif Mortenson [mailto:le...@ta...] 
>Sent: Wednesday, May 26, 2004 10:11 AM
>To: wra...@li...
>Subject: Re: [Wrapper-user] does wrapper depend on JAVA_HOME?
>
>Eugen,
>The Wrapper does not do anything with the JAVA_HOME environment
>variable. As long as you are not referencing it in your wrapper.conf file
>then there is also no way for the application running the JVM to reference
>it.
>JAVA_HOME is usually passed to the JVM using a system property like:
>
>-Djavahome=%JAVA_HOME%
>
>It is perfectly safe to do the following:
>wrapper.java.command=../jre/bin/java
>
>One option is to define the JAVA_HOME environment variable within
>your wrapper.conf file as follows:
>
>set.JAVA_HOME=../jre
>wrapper.java.command=%JAVA_HOME%/bin/java
>
>This has the benefit of making it easy to reference the JRE location
>throughout your wrapper.conf file. The user can also use a system
>value by simply commenting out the set line.
>
>Cheers,
>Leif
>
>
>
>Cocalea, Eugen wrote:
>
>  
>
>>Hello,
>>
>>This is a bit tricky, because not even me know what the question is about.
>>
>>I have a java application that I want to run as a windows service and
>>I use wrapper to do this.
>>
>>My app wrapper.conf used to have
>>
>>wrapper.java.command=%JAVA_HOME%/bin/java
>>
>>The problem is that I have to run different versions of the
>>application, that are certified against different JREs.
>>
>>So, my question is: if I hardcode the path to the JRE I need in
>>wrapper.java.command, do I need to check anything else to see if the
>>application really uses that JRE?
>>
>>Example:
>>
>>- JAVA_HOME points to JRE 1.3
>>
>>- I need to run the app with JRE 1.4
>>
>>- wrapper.java.command is <JRE1.4_install_path>/bin/java
>>
>>I should be safe, correct? *_Assuming my application doesn't use
>>JAVA_HOME._*
>>
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] does wrapper depend on JAVA_HOME?

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

Try running the Wrapper with wrapper.debug=true set in your wrapper.conf
file. This will cause the full command used to launch java to be logged.
This should hep you to narrow down the problem.

If you see something like %JAVA_HOME%, unexpanded in the generated
command, than means that the environment variable is not being registered
correctly.

What Wrapper version are you using. 3.1.0 handles spaces around the '='
in property declarations correctly, but the properties are not recognized in
earlier versions if the spaces are there.


Cheers,
Leif

Cocalea, Eugen wrote:

>Hi,
>
>Unfortunately, it seems that (in my case), set.JAVA_HOME=<path_to_java_home>
>doesn't work. I don't know why.
>
>I tried both setting it in wrapper.conf and supplying it in the command
>line, like:
>
>wrapper -c wrapper.conf "set.JAVA_HOME=<path_to_java_home>"
>
>In both cases, with
>
>wrapper.java.command = %JAVA_HOME%/bin/java
>
>the wrapper complains that it cannot execute the command.
>
>/EC
>
>-----Original Message-----
>From: Leif Mortenson [mailto:le...@ta...] 
>Sent: Wednesday, May 26, 2004 10:11 AM
>To: wra...@li...
>Subject: Re: [Wrapper-user] does wrapper depend on JAVA_HOME?
>
>Eugen,
>The Wrapper does not do anything with the JAVA_HOME environment
>variable. As long as you are not referencing it in your wrapper.conf file
>then there is also no way for the application running the JVM to reference
>it.
>JAVA_HOME is usually passed to the JVM using a system property like:
>
>-Djavahome=%JAVA_HOME%
>
>It is perfectly safe to do the following:
>wrapper.java.command=../jre/bin/java
>
>One option is to define the JAVA_HOME environment variable within
>your wrapper.conf file as follows:
>
>set.JAVA_HOME=../jre
>wrapper.java.command=%JAVA_HOME%/bin/java
>
>This has the benefit of making it easy to reference the JRE location
>throughout your wrapper.conf file. The user can also use a system
>value by simply commenting out the set line.
>
>Cheers,
>Leif
>
>
>
>Cocalea, Eugen wrote:
>
>  
>
>>Hello,
>>
>>This is a bit tricky, because not even me know what the question is about.
>>
>>I have a java application that I want to run as a windows service and
>>I use wrapper to do this.
>>
>>My app wrapper.conf used to have
>>
>>wrapper.java.command=%JAVA_HOME%/bin/java
>>
>>The problem is that I have to run different versions of the
>>application, that are certified against different JREs.
>>
>>So, my question is: if I hardcode the path to the JRE I need in
>>wrapper.java.command, do I need to check anything else to see if the
>>application really uses that JRE?
>>
>>Example:
>>
>>- JAVA_HOME points to JRE 1.3
>>
>>- I need to run the app with JRE 1.4
>>
>>- wrapper.java.command is <JRE1.4_install_path>/bin/java
>>
>>I should be safe, correct? *_Assuming my application doesn't use
>>JAVA_HOME._*
>>
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>

RE: [Wrapper-user] does wrapper depend on JAVA_HOME?

[Cocalea, E. <Co...@sy...>]

Hi,

Unfortunately, it seems that (in my case), set.JAVA_HOME=<path_to_java_home>
doesn't work. I don't know why.

I tried both setting it in wrapper.conf and supplying it in the command
line, like:

wrapper -c wrapper.conf "set.JAVA_HOME=<path_to_java_home>"

In both cases, with

wrapper.java.command = %JAVA_HOME%/bin/java

the wrapper complains that it cannot execute the command.

/EC

-----Original Message-----
From: Leif Mortenson [mailto:le...@ta...] 
Sent: Wednesday, May 26, 2004 10:11 AM
To: wra...@li...
Subject: Re: [Wrapper-user] does wrapper depend on JAVA_HOME?

Eugen,
The Wrapper does not do anything with the JAVA_HOME environment
variable. As long as you are not referencing it in your wrapper.conf file
then there is also no way for the application running the JVM to reference
it.
JAVA_HOME is usually passed to the JVM using a system property like:

-Djavahome=%JAVA_HOME%

It is perfectly safe to do the following:
wrapper.java.command=../jre/bin/java

One option is to define the JAVA_HOME environment variable within
your wrapper.conf file as follows:

set.JAVA_HOME=../jre
wrapper.java.command=%JAVA_HOME%/bin/java

This has the benefit of making it easy to reference the JRE location
throughout your wrapper.conf file. The user can also use a system
value by simply commenting out the set line.

Cheers,
Leif



Cocalea, Eugen wrote:

> Hello,
>
> This is a bit tricky, because not even me know what the question is about.
>
> I have a java application that I want to run as a windows service and
> I use wrapper to do this.
>
> My app wrapper.conf used to have
>
> wrapper.java.command=%JAVA_HOME%/bin/java
>
> The problem is that I have to run different versions of the
> application, that are certified against different JREs.
>
> So, my question is: if I hardcode the path to the JRE I need in
> wrapper.java.command, do I need to check anything else to see if the
> application really uses that JRE?
>
> Example:
>
> - JAVA_HOME points to JRE 1.3
>
> - I need to run the app with JRE 1.4
>
> - wrapper.java.command is <JRE1.4_install_path>/bin/java
>
> I should be safe, correct? *_Assuming my application doesn't use
> JAVA_HOME._*
>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

RE: [Wrapper-user] what command to execute

[Annam, S. <sun...@ea...>]

Leif,

I did create script file. Initially it did not work but later I figured
out I transferred script file to HP-UX as binary. Therefore, it had all
control characters.

Now I am facing another issue. I am getting the following message.

Unable to load the Wrapper's native library because the file
jvm 1    |           'libwrapper.so' could not be located in the
following
jvm 1    |           java.library.path:
jvm 1    |
/u04/oracle/testora/iAS/Apache/Jserv/servlets/loadModel/b
in/.
jvm 1    |           Please see the documentation for the
wrapper.java.library.p
ath
jvm 1    |           configuration property.
jvm 1    |           System signals will not be handled correctly.

I searched the mailing list and found some links. We are using HP-UX 32
bit. From the old posting, I am not clear whether issue is with 32 bit
or 64 bit?=20

Thanks for your help.

Sunil




-----Original Message-----
From: wra...@li...
[mailto:wra...@li...] On Behalf Of Leif
Mortenson
Sent: Wednesday, May 26, 2004 5:00 PM
To: wra...@li...
Subject: Re: [Wrapper-user] what command to execute

Annam, Sunil wrote:

> I have an application myApps1 in a package myApps. Right now I use=20
> 'java myApps.myApps1' on command prompt to execute my application.
>
> I went through Wrapper documentation and JBoss example. I also created

> similar directory structure and conf file for my application.
>
> Now what should I do? I mean what command to execute on command
prompt.
>
The integration tutorial should have had you create 3 batch files for=20
Windows, or a
shell script for UNIX platforms.

Running them will launch the Wrapper and your program. Is that what you=20
are asking?

Cheers,
Leif



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.

Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] what command to execute

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

Annam, Sunil wrote:

> I have an application myApps1 in a package myApps. Right now I use 
> ‘java myApps.myApps1’ on command prompt to execute my application.
>
> I went through Wrapper documentation and JBoss example. I also created 
> similar directory structure and conf file for my application.
>
> Now what should I do? I mean what command to execute on command prompt.
>
The integration tutorial should have had you create 3 batch files for 
Windows, or a
shell script for UNIX platforms.

Running them will launch the Wrapper and your program. Is that what you 
are asking?

Cheers,
Leif

Re: [Wrapper-user] what is the memory and cpu footprint of the wrapper itself?

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

Jennifer Kolar wrote:

> I ran my java application through optimize-it and looked at the % of 
> time the CPU spent in the Wrapper Manager - which is a static object 
> in my VM since I reference it to call restarts and also to enable and 
> disable monitoring pings.  I also ran the WrapperSimpleApp w/ it 
> calling my app under optimize-it.
>
> I found that under 3.0.5 the % of time the CPU spent in wrapper code  
> was about 15%
> under 3.1.0 (with ticktimer on) the % of time the CPU spent in wrapper 
> code was about 38%

There is a thread in the WrapperManager that is cycling at a 100ms 
interval where
each cycle is a "tick".   That is a little tighter than the old thread 
which was simply
pinging the JNI code for system signals.

What is the rest of the application doing at this time.   If it is idle 
then I am not surprised
at the percentage jump.   But the new thread should still be quite light 
weight.   When
running under reasonably high load.  The % of CPU used by the thread in 
3.0.5 and
3.1.0 should both be insignificant.    Are you seeing results different 
from what I am
expecting?

> I then used purify to run the wrapper.exe to look for leaks on that 
> side of things, and I didn't find any particular problems..

Good to hear.  Thank you.

> Thanks for the memory footprint information and the expected CPU load 
> info.

Cheers,
Leif

[Wrapper-user] what command to execute

[Annam, S. <sun...@ea...>]

I have an application myApps1 in a package myApps. Right now I use 'java
myApps.myApps1' on command prompt to execute my application.

=20

I went through Wrapper documentation and JBoss example. I also created
similar directory structure and conf file for my application.=20

=20

Now what should I do? I mean what command to execute on command prompt.

=20

Re: [Wrapper-user] process not restarting when cpu at 100%

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

Jennifer Kolar wrote:

> Sorry if I wasn't clear.
> What I am seeing is the processes under the wrapper just hang. They 
> don't exit, they don't report errors, they just hang.
> The CPU is at 100% and has been for some time. I have on INFO level 
> logging from the wrapper which I believe is enough to see messages
> about not getting enough CPU time..

Is the entire JVM hung, or is your application simply not responding.   
The debug
output should show which is the case.  If the JVM were truly hung then 
it would
not be responding to ping requests and the JVM would be restarted by the
Wrapper after your 300 second ping timeout expires.   As long as the JVM is
responding to pings then it will not restart the JVM even if the rest of 
your
application is "hung".

>
> I will try to reproduce w/ debug on so I can give more information. I 
> hopefully just rolled out code to fix the CPU load issue, so that may 
> be harder :)

You may want to temporarily back out your change and create the debug 
output to
make sure that there is not a wrapper related problem.

>
> So on the other note, for 3.1.0 you are saying that if there is a ping 
> timeout and the wrapper restarts, the second time there is a restart 
> request it will  not happen? This is functionality I use as well...

There are two ways for a ping timeout to occur.   If the Wrapper sends 
the JVM a
ping and the JVM does not respond within the specified time then the 
Wrapper will
assume that the JVM is hung, kill it and then restart the JVM.

The second way is if the JVM does not receive any ping requests for 
longer than the
ping timeout.   In this case, the JVM assumes that the Wrapper process 
was killed
or that something bad happened to the communications socket.   To be 
safe, it quits.
If the Wrapper is still alive then it should restart a new JVM 
instance.   This was
working through 3.0.5.   But when I reorganized the Wrapper's state 
engine for
3.1.0, I introduced a bug where the Wrapper is not interpreting that JVM 
exit as
a desire to shutdown the Wrapper as well.   Rather than launching a new 
JVM, the
Wrapper is simply stopping.  This is what I fixed for 3.1.1.

Normal restart requests and restarts caused by other problems are all 
working
correctly.  The case that is not working is quite rare.  But I was 
thinking that you
may have been encountering it.  From this message however, it does not sound
like you are.

Cheers,
Leif

> On May 26, 2004, at 12:55 AM, Leif Mortenson wrote:
>
>> Jennifer,
>>    Sorry.  I may still be reacting to jet lag.  But I am not clear on 
>> your problem.
>> When you say that the "processes just stop running".   Are you 
>> meaning that the
>> JVM and Wrapper are stopping?   If so, what are you seeing in your 
>> wrapper.log?
>>    Would it be possible for you to reproduce this with 
>> wrapper.debug=true set
>> so that I can see what is going on a little better.
>>
>>    I did just fix a problem for 3.1.1 where the JVM was not being 
>> restarted in the
>> event that the JVM restarted itself due to a ping timeout.   This was 
>> a bug introduced
>> in 3.1.0 and does not sound like the problem you are seeing.
>>
>>    When the CPU(s) is pegged at 100% that does not mean that all 
>> processes are not
>> getting any CPU.  If the applications are being nice then other 
>> processes will get just
>> as much CPU as they need, but not any more.  The total CPU ends up 
>> pegged.
>>
>> Cheers,
>> Leif
>>
>> Jennifer Kolar wrote:
>>
>>> I have processes running under servicewrapper 3.1.0 that are 
>>> regularly becoming CPU bound.. which is a separate problem in and of 
>>> itself that I am addressing..
>>>
>>> However, I would expect the servicewrapper to restart those 
>>> services.... (I have seen this same problem under 3.0.5 by the way)
>>>
>>>
>>> What I see is that the processes just stop running- cpu is at 100% 
>>> (4 cpu machine- all pegged).. no errors, no messages from the wrapper.
>>> Any ideas?
>>>
>>> How is it that  wrapper code has the cpu cycles to run and know to 
>>> restart the process if the CPU is at 100%?
>>>
>>> here are the settings in my properties files that would have any 
>>> relationship to this at all.
>>>
>>> # How long to wait [seconds] between when the JVM says it has stopped
>>> # and seeing if the JVM has actually terminated.
>>> # A value of <0 means no timeout will be enforced.
>>> wrapper.jvm_exit.timeout=30
>>>
>>> # How long to wait for the cpu [seconds] before declaring it timed-out
>>> # a value of <0 means no timeout will be enforced.
>>> wrapper.cpu.timeout=10
>>>
>>> # How long [seconds] to allow between pings before considering the 
>>> VM timed-out
>>> # Max allowed time is 3600 sec or 1 hour.
>>> # Must be atleast 5 seconds longer than the ping interval.
>>> # Must be longer than the CPU timeout.
>>> # A value of <0 means no timeout will be enforced.
>>> wrapper.ping.timeout=300
>>>
>>> # How often [seconds] to send pings to the JVM to see if it is alive
>>> # Must be atleast 1 second.
>>> wrapper.ping.interval=5
>>>
>>> # How long [seconds] to wait before issuing reset of JVM- only applies
>>> # to resets, not to initial start.
>>> wrapper.restart.delay=10
>>>
>>> # Max number of times to restart(or start) invocation of JVM
>>> # must be atleast 1
>>> # Note- this only applies to startup attempts, not anything else
>>> # best to make atleast 2...
>>> wrapper.max_failed_invocations=3
>>>
>>> # How long [seconds] an application has to run to be considered 
>>> successfully invoked.
>>> # don't leave too long- since if we restart between processing and 
>>> have been
>>> # running less than this time we will only be allowed 
>>> "max_failed_invocations"
>>> # to restart.. and not the usual unlimited number.
>>> wrapper.successful_invocation_time=2
>>>
>>> # How long [seconds] to allow for startup before declaring it timed-out
>>> # and restarting
>>> # Must be longer than the CPU timeout.
>>> # A value of <0 means no timeout will be enforced.
>>> wrapper.startup.timeout=30
>>>
>>> #whether to use system time or the internal tick timer
>>> # set to false to use new experimental tick timer
>>> # version 3.1.0 and later
>>> wrapper.use_system_time=FALSE
>>>
>>> # Whether you want a thread dump if the JVM failed to exit nicely
>>> wrapper.request_thread_dump_on_failed_jvm_exit=FALSE
>>>
>>> #Whether or not system signals should be ignored
>>> # If set to TRUE, CTRL-C will NOT stop the process....
>>> # Only System.exit (if shutdown hooks are not disabled) and internal
>>> # programatic stop commands will stop the service. (and of course 
>>> through
>>> # the service control panel)
>>> wrapper.ignore_signals=TRUE
>>>
>>> #whether or not shutdown hooks should be ignored
>>> # Setting this to TRUE means System.exit will result in
>>> # a restart. Setting it to FALSE means System.exit will be treated
>>> # as a purposeful shutdown and actually exit.
>>> wrapper.disable_shutdown_hook=TRUE
>>>
>>>
>>> Thanks,
>>>  Jennifer
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: Oracle 10g
>>> Get certified on the hottest thing ever to hit the market... Oracle 
>>> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
>>> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>>> _______________________________________________
>>> Wrapper-user mailing list
>>> Wra...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: Oracle 10g
>> Get certified on the hottest thing ever to hit the market... Oracle 
>> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
>> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] what is the memory and cpu footprint of the wrapper itself?

[Jennifer K. <jk...@si...>]

I ran my java application through optimize-it and looked at the % of 
time the CPU spent in the Wrapper Manager - which is a static object in 
my VM since I reference it to call restarts and also to enable and 
disable monitoring pings.  I also ran the WrapperSimpleApp w/ it 
calling my app under optimize-it.

I found that under 3.0.5 the % of time the CPU spent in wrapper code  
was about 15%
under 3.1.0 (with ticktimer on) the % of time the CPU spent in wrapper 
code was about 38%

I then used purify to run the wrapper.exe to look for leaks on that 
side of things, and I didn't find any particular problems..

Thanks for the memory footprint information and the expected CPU load 
info.

Jennifer



On May 26, 2004, at 1:04 AM, Leif Mortenson wrote:

> Jennifer,
>    Memory usage has been going up slightly with each release as new 
> features are
> added.   But I try to keep the footprint as small as possible.   One 
> Windows,
> 3.1.0 requires around 1700KB this depends on the application and the 
> output sent
> to the console however.  Most internal buffers are dynamic.
>
>    There was a slight performance hit in 3.1.0 when processing lots 
> and lots of console
> output.  This was caused by a fix to a synchronization problem with 
> internal buffers
> used by the logging system.   The hit was very minor however.
>    What are you doing that you are even able to measure such a change. 
> Even when sending lots and lots of output to the console the Wrapper 
> CPU is still
> usually down around 1-2% of total load.   When there is no output it 
> always shows
> as 0%
>
>    As for the memory of your JVM.   The Wrapper requires a slight 
> amount of
> memory on top of what your application would normally use for its own 
> classes,
> but this is quite minor.   Your should be able to tune the max memory 
> value
> depending on your application.  I have small applications that run in 
> just a few
> MB where setting the max memory to 8MB works just fine.  Could probably
> even be set to 4MB or so.
>
>    Let me know if I did not answer you.
>
> Cheers,
> Leif
>
> Jennifer Kolar wrote:
>
>> For wrapper 3.1.0 and 3.0.5 under Windows 2000-- using sun's JVM 
>> 1.4.2  what amount of memory do I need to allocate for the
>> wrapper itself?
>> Should I expect this number to be higher under 3.1.0?
>>
>> what about CPU usage. what % of CPU usage should I expect w/ default 
>> configuration parameters?
>> I am finding that the CPU load from 3.1.0 is about 20% higher from 
>> the wrapper  than with 3.0.5.
>>
>> I am running multiple instances of processes wrapped with the wrapper 
>> and thus can't just allocate a huge amount of memory to each process.
>>
>> Thanks,
>> Jennifer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] process not restarting when cpu at 100%

[Jennifer K. <jk...@si...>]

Sorry if I wasn't clear.
What I am seeing is the processes under the wrapper just hang. They 
don't exit, they don't report errors, they just hang.
The CPU is at 100% and has been for some time. I have on INFO level 
logging from the wrapper which I believe is enough to see messages
about not getting enough CPU time..

I will try to reproduce w/ debug on so I can give more information. I 
hopefully just rolled out code to fix the CPU load issue, so that may 
be harder :)

So on the other note, for 3.1.0 you are saying that if there is a ping 
timeout and the wrapper restarts, the second time there is a restart 
request it will  not happen? This is functionality I use as well...

thanks
Jennifer

On May 26, 2004, at 12:55 AM, Leif Mortenson wrote:

> Jennifer,
>    Sorry.  I may still be reacting to jet lag.  But I am not clear on 
> your problem.
> When you say that the "processes just stop running".   Are you meaning 
> that the
> JVM and Wrapper are stopping?   If so, what are you seeing in your 
> wrapper.log?
>    Would it be possible for you to reproduce this with 
> wrapper.debug=true set
> so that I can see what is going on a little better.
>
>    I did just fix a problem for 3.1.1 where the JVM was not being 
> restarted in the
> event that the JVM restarted itself due to a ping timeout.   This was 
> a bug introduced
> in 3.1.0 and does not sound like the problem you are seeing.
>
>    When the CPU(s) is pegged at 100% that does not mean that all 
> processes are not
> getting any CPU.  If the applications are being nice then other 
> processes will get just
> as much CPU as they need, but not any more.  The total CPU ends up 
> pegged.
>
> Cheers,
> Leif
>
> Jennifer Kolar wrote:
>
>> I have processes running under servicewrapper 3.1.0 that are 
>> regularly becoming CPU bound.. which is a separate problem in and of 
>> itself that I am addressing..
>>
>> However, I would expect the servicewrapper to restart those 
>> services.... (I have seen this same problem under 3.0.5 by the way)
>>
>>
>> What I see is that the processes just stop running- cpu is at 100% (4 
>> cpu machine- all pegged).. no errors, no messages from the wrapper.
>> Any ideas?
>>
>> How is it that  wrapper code has the cpu cycles to run and know to 
>> restart the process if the CPU is at 100%?
>>
>> here are the settings in my properties files that would have any 
>> relationship to this at all.
>>
>> # How long to wait [seconds] between when the JVM says it has stopped
>> # and seeing if the JVM has actually terminated.
>> # A value of <0 means no timeout will be enforced.
>> wrapper.jvm_exit.timeout=30
>>
>> # How long to wait for the cpu [seconds] before declaring it timed-out
>> # a value of <0 means no timeout will be enforced.
>> wrapper.cpu.timeout=10
>>
>> # How long [seconds] to allow between pings before considering the VM 
>> timed-out
>> # Max allowed time is 3600 sec or 1 hour.
>> # Must be atleast 5 seconds longer than the ping interval.
>> # Must be longer than the CPU timeout.
>> # A value of <0 means no timeout will be enforced.
>> wrapper.ping.timeout=300
>>
>> # How often [seconds] to send pings to the JVM to see if it is alive
>> # Must be atleast 1 second.
>> wrapper.ping.interval=5
>>
>> # How long [seconds] to wait before issuing reset of JVM- only applies
>> # to resets, not to initial start.
>> wrapper.restart.delay=10
>>
>> # Max number of times to restart(or start) invocation of JVM
>> # must be atleast 1
>> # Note- this only applies to startup attempts, not anything else
>> # best to make atleast 2...
>> wrapper.max_failed_invocations=3
>>
>> # How long [seconds] an application has to run to be considered 
>> successfully invoked.
>> # don't leave too long- since if we restart between processing and 
>> have been
>> # running less than this time we will only be allowed 
>> "max_failed_invocations"
>> # to restart.. and not the usual unlimited number.
>> wrapper.successful_invocation_time=2
>>
>> # How long [seconds] to allow for startup before declaring it 
>> timed-out
>> # and restarting
>> # Must be longer than the CPU timeout.
>> # A value of <0 means no timeout will be enforced.
>> wrapper.startup.timeout=30
>>
>> #whether to use system time or the internal tick timer
>> # set to false to use new experimental tick timer
>> # version 3.1.0 and later
>> wrapper.use_system_time=FALSE
>>
>> # Whether you want a thread dump if the JVM failed to exit nicely
>> wrapper.request_thread_dump_on_failed_jvm_exit=FALSE
>>
>> #Whether or not system signals should be ignored
>> # If set to TRUE, CTRL-C will NOT stop the process....
>> # Only System.exit (if shutdown hooks are not disabled) and internal
>> # programatic stop commands will stop the service. (and of course 
>> through
>> # the service control panel)
>> wrapper.ignore_signals=TRUE
>>
>> #whether or not shutdown hooks should be ignored
>> # Setting this to TRUE means System.exit will result in
>> # a restart. Setting it to FALSE means System.exit will be treated
>> # as a purposeful shutdown and actually exit.
>> wrapper.disable_shutdown_hook=TRUE
>>
>>
>> Thanks,
>>  Jennifer
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: Oracle 10g
>> Get certified on the hottest thing ever to hit the market... Oracle 
>> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
>> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Filters: triggering on things other than strings

[Wrapper U. <wr...@co...>]

> Good news.  The ability to trigger on a JVM exit code was added in 3.1.0.
> Take a look at the docs and let me know if this will do what you need.
> http://wrapper.tanukisoftware.org/doc/english/prop-on-exit-n.html

Yes, that is good news. I was actually using 3.1.0 I believe, but I was
probably looking at an older version of the docs and didn't see that
property (or it was there and I just missed it).
It looks to be more or less what I need.

> >Another (totally separate) solution would be (and I'm just brainstorming
> >here) putting some dependencies on different wrapper applications.
Something
> >like writing a totally separate script that somehow checks if service0 is
> >running (service0 status) before it launches service1...
> >
> >
> This is available on Windows.   But UNIX does not really provide a
> mechanism to do
> this other than specifying startup and shutdown orders in the various
> run levels.

Well, this is less important now, assuming I can get the exit code thing to
work. I'll test it sometime today hopefully.

Thanks,
Aiman

Re: [Wrapper-user] "" included before starting classpath?

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

Prashant,
You can see the exact command generated by the Wrapper to launch the JVM by
running the Wrapper with debug output enabled.

wrapper.debug=true

The answer though is yes.  The generated classpath is enclosed in quotes on
Windows.  This was necessary to make things work reliably with paths 
containing
spaces.

Cheers,
Leif

Prashant wrote:

> If i have class path enties like this in my conf file.
>
> wrapper.java.classpath.1=%ps_root%/services/bin/wrapper.jar
> wrapper.java.classpath.2=%ps_root%/server/lib/server_patch.jar
> wrapper.java.classpath.3=%ps_root%/server/lib/classpath.jar
> wrapper.java.classpath.4=%JAVA_HOME%/lib/tools.jar
> wrapper.java.classpath.5=%JAVA_HOME%/jre/lib/rt.jar
>
>
> Does Wrapper include Quotes (") when passing -classpath when firing 
> "java" command On Win 32?
>
> something like
>
> java -classpath "$wrapper.java.classpath.1" com.something.MaingProgram
>
> I am using Integration Method 1 and Wrapper 3.0.5.
>
> Thanks
> Prashant
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] "" included before starting classpath?

[Prashant <pra...@pr...>]

If i have class path enties like this in my conf file.

wrapper.java.classpath.1=%ps_root%/services/bin/wrapper.jar
wrapper.java.classpath.2=%ps_root%/server/lib/server_patch.jar
wrapper.java.classpath.3=%ps_root%/server/lib/classpath.jar
wrapper.java.classpath.4=%JAVA_HOME%/lib/tools.jar
wrapper.java.classpath.5=%JAVA_HOME%/jre/lib/rt.jar


Does Wrapper include Quotes (") when passing -classpath when firing 
"java" command On Win 32?

something like

java -classpath "$wrapper.java.classpath.1" com.something.MaingProgram

I am using Integration Method 1 and Wrapper 3.0.5.

Thanks
Prashant

RE: [Wrapper-user] does wrapper depend on JAVA_HOME?

[Cocalea, E. <Co...@sy...>]

Leif,

Thanks, I didn't notice the set. command. So, I can have a different
JAVA_HOME variable for every wrapper I run on a machine. This sounds great
and it's exactly what I needed.

/EC

-----Original Message-----
From: Leif Mortenson [mailto:le...@ta...] 
Sent: Wednesday, May 26, 2004 10:11 AM
To: wra...@li...
Subject: Re: [Wrapper-user] does wrapper depend on JAVA_HOME?

Eugen,
The Wrapper does not do anything with the JAVA_HOME environment
variable. As long as you are not referencing it in your wrapper.conf file
then there is also no way for the application running the JVM to reference
it.
JAVA_HOME is usually passed to the JVM using a system property like:

-Djavahome=%JAVA_HOME%

It is perfectly safe to do the following:
wrapper.java.command=../jre/bin/java

One option is to define the JAVA_HOME environment variable within
your wrapper.conf file as follows:

set.JAVA_HOME=../jre
wrapper.java.command=%JAVA_HOME%/bin/java

This has the benefit of making it easy to reference the JRE location
throughout your wrapper.conf file. The user can also use a system
value by simply commenting out the set line.

Cheers,
Leif



Cocalea, Eugen wrote:

> Hello,
>
> This is a bit tricky, because not even me know what the question is about.
>
> I have a java application that I want to run as a windows service and
> I use wrapper to do this.
>
> My app wrapper.conf used to have
>
> wrapper.java.command=%JAVA_HOME%/bin/java
>
> The problem is that I have to run different versions of the
> application, that are certified against different JREs.
>
> So, my question is: if I hardcode the path to the JRE I need in
> wrapper.java.command, do I need to check anything else to see if the
> application really uses that JRE?
>
> Example:
>
> - JAVA_HOME points to JRE 1.3
>
> - I need to run the app with JRE 1.4
>
> - wrapper.java.command is <JRE1.4_install_path>/bin/java
>
> I should be safe, correct? *_Assuming my application doesn't use
> JAVA_HOME._*
>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] what is the memory and cpu footprint of the wrapper itself?

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

Jennifer,
    Memory usage has been going up slightly with each release as new 
features are
added.   But I try to keep the footprint as small as possible.   One 
Windows,
3.1.0 requires around 1700KB this depends on the application and the 
output sent
to the console however.  Most internal buffers are dynamic.

    There was a slight performance hit in 3.1.0 when processing lots and 
lots of console
output.  This was caused by a fix to a synchronization problem with 
internal buffers
used by the logging system.   The hit was very minor however.
    What are you doing that you are even able to measure such a change. 
Even when sending lots and lots of output to the console the Wrapper CPU 
is still
usually down around 1-2% of total load.   When there is no output it 
always shows
as 0%

    As for the memory of your JVM.   The Wrapper requires a slight amount of
memory on top of what your application would normally use for its own 
classes,
but this is quite minor.   Your should be able to tune the max memory value
depending on your application.  I have small applications that run in 
just a few
MB where setting the max memory to 8MB works just fine.  Could probably
even be set to 4MB or so.

    Let me know if I did not answer you.

Cheers,
Leif

Jennifer Kolar wrote:

> For wrapper 3.1.0 and 3.0.5 under Windows 2000-- using sun's JVM 
> 1.4.2  what amount of memory do I need to allocate for the
> wrapper itself?
> Should I expect this number to be higher under 3.1.0?
>
> what about CPU usage. what % of CPU usage should I expect w/ default 
> configuration parameters?
> I am finding that the CPU load from 3.1.0 is about 20% higher from the 
> wrapper  than with 3.0.5.
>
> I am running multiple instances of processes wrapped with the wrapper 
> and thus can't just allocate a huge amount of memory to each process.
>
> Thanks,
> Jennifer

Re: [Wrapper-user] process not restarting when cpu at 100%

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

Jennifer,
    Sorry.  I may still be reacting to jet lag.  But I am not clear on 
your problem.
When you say that the "processes just stop running".   Are you meaning 
that the
JVM and Wrapper are stopping?   If so, what are you seeing in your 
wrapper.log?
    Would it be possible for you to reproduce this with 
wrapper.debug=true set
so that I can see what is going on a little better.

    I did just fix a problem for 3.1.1 where the JVM was not being 
restarted in the
event that the JVM restarted itself due to a ping timeout.   This was a 
bug introduced
in 3.1.0 and does not sound like the problem you are seeing.

    When the CPU(s) is pegged at 100% that does not mean that all 
processes are not
getting any CPU.  If the applications are being nice then other 
processes will get just
as much CPU as they need, but not any more.  The total CPU ends up pegged.

Cheers,
Leif

Jennifer Kolar wrote:

> I have processes running under servicewrapper 3.1.0 that are regularly 
> becoming CPU bound.. which is a separate problem in and of itself that 
> I am addressing..
>
> However, I would expect the servicewrapper to restart those 
> services.... (I have seen this same problem under 3.0.5 by the way)
>
>
> What I see is that the processes just stop running- cpu is at 100% (4 
> cpu machine- all pegged).. no errors, no messages from the wrapper.
> Any ideas?
>
> How is it that  wrapper code has the cpu cycles to run and know to 
> restart the process if the CPU is at 100%?
>
> here are the settings in my properties files that would have any 
> relationship to this at all.
>
> # How long to wait [seconds] between when the JVM says it has stopped
> # and seeing if the JVM has actually terminated.
> # A value of <0 means no timeout will be enforced.
> wrapper.jvm_exit.timeout=30
>
> # How long to wait for the cpu [seconds] before declaring it timed-out
> # a value of <0 means no timeout will be enforced.
> wrapper.cpu.timeout=10
>
> # How long [seconds] to allow between pings before considering the VM 
> timed-out
> # Max allowed time is 3600 sec or 1 hour.
> # Must be atleast 5 seconds longer than the ping interval.
> # Must be longer than the CPU timeout.
> # A value of <0 means no timeout will be enforced.
> wrapper.ping.timeout=300
>
> # How often [seconds] to send pings to the JVM to see if it is alive
> # Must be atleast 1 second.
> wrapper.ping.interval=5
>
> # How long [seconds] to wait before issuing reset of JVM- only applies
> # to resets, not to initial start.
> wrapper.restart.delay=10
>
> # Max number of times to restart(or start) invocation of JVM
> # must be atleast 1
> # Note- this only applies to startup attempts, not anything else
> # best to make atleast 2...
> wrapper.max_failed_invocations=3
>
> # How long [seconds] an application has to run to be considered 
> successfully invoked.
> # don't leave too long- since if we restart between processing and 
> have been
> # running less than this time we will only be allowed 
> "max_failed_invocations"
> # to restart.. and not the usual unlimited number.
> wrapper.successful_invocation_time=2
>
> # How long [seconds] to allow for startup before declaring it timed-out
> # and restarting
> # Must be longer than the CPU timeout.
> # A value of <0 means no timeout will be enforced.
> wrapper.startup.timeout=30
>
> #whether to use system time or the internal tick timer
> # set to false to use new experimental tick timer
> # version 3.1.0 and later
> wrapper.use_system_time=FALSE
>
> # Whether you want a thread dump if the JVM failed to exit nicely
> wrapper.request_thread_dump_on_failed_jvm_exit=FALSE
>
> #Whether or not system signals should be ignored
> # If set to TRUE, CTRL-C will NOT stop the process....
> # Only System.exit (if shutdown hooks are not disabled) and internal
> # programatic stop commands will stop the service. (and of course through
> # the service control panel)
> wrapper.ignore_signals=TRUE
>
> #whether or not shutdown hooks should be ignored
> # Setting this to TRUE means System.exit will result in
> # a restart. Setting it to FALSE means System.exit will be treated
> # as a purposeful shutdown and actually exit.
> wrapper.disable_shutdown_hook=TRUE
>
>
> Thanks,
>  Jennifer
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Starting application with pribileged port under Linux/Unix

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

Thorsten,
This issue is discussed in detail on the following Feature Requst page:
https://sourceforge.net/tracker/index.php?func=detail&aid=490806&group_id=39428&atid=425190

I had decided that this was not possible.  See above.

I will take a look at the commons daemon package and see how it works.

http://jakarta.apache.org/commons/daemon/jsvc.html

Unless they are using a custom version of java.exe, to open the port 
before any
java threads are created then this is a chicken and the egg problem.  
That may
be what their jsvc binary is.   Will take a closer look.

Cheers,
Leif


Thorsten Kamann wrote:

> Hello  Mailinglist,
>
> I want to start the Tomcat-Server 5.0.x with the current Wrapper.
> With the Commons-Demon Package I can start the Tomcat with one of the
> privileged ports (< 1024) without runnung it with root-privileges like 
> e.g.
> Apache.
>
> Can I configure the wrapper to achieve the same behaviour?
>
> Best regards
> Thorsten
>

Re: [Wrapper-user] Converting RMID into a NT/2000 service

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

Zac,
All I can say is ouch!   You must like pain!

There is a much easier way to do this.   (Not that sun makes it easy to 
find out about)
The rmid.exe file is actually simply running a sun class.   To get 
things running under
the Wrapper, you will need to do the follow.

This assumes that you have read over method #1 of the integration 
documentation.
http://wrapper.tanukisoftware.org/doc/english/integrate.html

First, the Wrapper classes will be calling RMI daemon code on startup so 
you will
need to give privilege to them.   Create a file called. rmiserver.policy 
in your conf
directory with the following contents.
---
// Give Wrapper classes full permissions
grant codeBase "file:../lib/wrapper.jar" {
permission java.security.AllPermission;
};
---

Now you will need to set the following properties in your wrapper.conf file.
Copy it over from the src/conf/wrapper.conf.in file that ships with the 
Wrapper.

---
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.additional.1=-Djava.security.policy=../conf/rmiserver.policy
wrapper.app.parameter.1=sun.rmi.registry.RegistryImpl
---

You will also want to set the NT properties at the bottom of the file.

Everything should now work for you.   Give it a try as a console before
trying to get things working as an NT service.   Let me know if I have 
any typos
in the above.

As for your questions about the Wrapper protecting child JVMs from 
system signals.
The answer is no.  You must launch the child JVMs with the -Xrs 
parameter so it
will ignore them on its own.   You can not set this for the JVM launched 
by the
Wrapper however or you WILL run into problems.  The Wrapper protects its own
JVM already so this should never be necessary.

Cheers,
Leif


zge...@ex... wrote:

>I need to convert the Java RMID process into a windows service. 
>
>
>
>Using integration method 3 I did the following:
>
>1) Create a WrapperListener implementation that uses java.lang.Runtime.exec(...) to launch "rmid.exe". The implementation's "stop" method similarly launches "rmid.exe -stop" to stop the previously launched rmid process.
>
>2) Install the WrapperListener implementation as an NT service.
>
>
>
>On installing the service and starting it and after 
>
>activating a remote object in a separate Activatable Server (that rmid process takes care of launching), I see the following processes (among others) in the "Windows Task Manager". 
>
>#a) wrapper.exe
>
>#b) java.exe (the WrapperListener implemenation)
>
>#c) rmid.exe (launched by #b)
>
>#d) java.exe (activated by rmid.exe in #c).
>
>
>
>On stopping the service all of these processes come down cleanly. 
>
>
>
>Here's the problem:
>
>After launching the service - if I logoff, rmid.exe (#c) and the java.exe (#d) process seem to shutdown. When I login again, all four processes are gone. 
>
>
>
>In the WrapperListener implementation I do get the Service Control Event indicating that a logoff has happened - The current behavior is to let the native WrapperManager handle all service control events. 
>
>
>
>Are processes launched from the WrapperListener implementation under the control of the service - i.e. live and die with the life of the service?
>
>
>
>Has anyone successfully implemented rmid as a service (especially including its activation features) not just as a registry? 
>
>
>
>Can JSW be used for a case like this to first launch rmid.exe which  can then internally launch multiple JVMs that can survive login/logoffs.
>
>
>
>Thanks for all your help in advance.
>
>Zac George
>  
>

Re: [Wrapper-user] does wrapper depend on JAVA_HOME?

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

Eugen,
The Wrapper does not do anything with the JAVA_HOME environment
variable. As long as you are not referencing it in your wrapper.conf file
then there is also no way for the application running the JVM to reference
it.
JAVA_HOME is usually passed to the JVM using a system property like:

-Djavahome=%JAVA_HOME%

It is perfectly safe to do the following:
wrapper.java.command=../jre/bin/java

One option is to define the JAVA_HOME environment variable within
your wrapper.conf file as follows:

set.JAVA_HOME=../jre
wrapper.java.command=%JAVA_HOME%/bin/java

This has the benefit of making it easy to reference the JRE location
throughout your wrapper.conf file. The user can also use a system
value by simply commenting out the set line.

Cheers,
Leif



Cocalea, Eugen wrote:

> Hello,
>
> This is a bit tricky, because not even me know what the question is about.
>
> I have a java application that I want to run as a windows service and
> I use wrapper to do this.
>
> My app wrapper.conf used to have
>
> wrapper.java.command=%JAVA_HOME%/bin/java
>
> The problem is that I have to run different versions of the
> application, that are certified against different JREs.
>
> So, my question is: if I hardcode the path to the JRE I need in
> wrapper.java.command, do I need to check anything else to see if the
> application really uses that JRE?
>
> Example:
>
> - JAVA_HOME points to JRE 1.3
>
> - I need to run the app with JRE 1.4
>
> - wrapper.java.command is <JRE1.4_install_path>/bin/java
>
> I should be safe, correct? *_Assuming my application doesn't use
> JAVA_HOME._*
>

Re: [Wrapper-user] reboot on linux

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

Chris,
    I would need to see the debug log output of the wrapper to tell you 
the exact
reason why your application is being restarted.   But most likely it is 
a ping timeout
issue.
    You can extend this using the following property.   Be sure to read 
the docs
first so you understand the drawbacks of doing so.
http://wrapper.tanukisoftware.org/doc/english/prop-ping-timeout.html

    Another option is to try out the new tick based timer.  It is still 
considered
experimental, but from my tests it has been performing more reliably under
high loads.   One user has experienced a crash while using it however that
I have been trying to track down (Additional testers wanted :-)
http://wrapper.tanukisoftware.org/doc/english/prop-use-system-time.html

Cheers,
Leif

chris opler wrote:

> Hi -- I am running the wrapper on redhat 9.0 w jdk 1.4.2 -- i get 
> occasional reboots of my jvm by the wrapper during high load. is there 
> a way to configure the wrapper that it ** never **  automatically 
> restarts the jvm due to timeouts, but will do so via command (app 
> restart) or using jmx.
>
> Thank you,
>
> Chris

Re: [Wrapper-user] CTRL-C not trapped in sercice console mode!

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

Ben,
    When I tried this out, I had the experience that the Wrapper process was
immediately brought down when pressing CTRL-C.   The problem is that the
Wrapper was not logging its shutdown.   It did appear to be shutting down
the JVM correctly however.

    At any rate this is a bug.  The problem is that I was registering my 
control
handler before the service's console was being created.  It appears that the
handler is not applied to the new console in this case.   I have fixed 
this for
the next 3.1.1 release by making sure that the handler is now registered
after the console is created.   This is only an issue when running as an NT
service with the following two properties set.

wrapper.ntservice.console=true
wrapper.ntservice.interactive=true

    Thanks for pointing this out.

Cheers,
Leif

Ben David, Tomer wrote:

>Hi
>
>When I'm running wrapper in regular console mode ( -c ) then it trapps perfectly the CTRL-C and I see on console:
>
>wrapper  | CTRL-C trapped.  Shutting down.
>
>However if I'm running in a service mode with console enabled, then I dont see this line on screen, and my application donesn't shut down properly :(
>
>Anyone knows why?
>  
>

Re: [Wrapper-user] Filters: triggering on things other than strings

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

Aiman,
See below.

Wrapper User wrote:

>As I understand it now, the wrapper can only trigger on an output string.
>
>Is there any way (or near-future plans) to trigger on something other than
>output. For example, if the program throws an Exception, or trigger on the
>exit code of the application?
>
>In my specific case, I'm having an application "service1" (which I'm under
>the assumption can't be changed to display different output) tries to
>connect to a (naming) server "service0". Note that service0 will also be
>launched by a wrapper. So, basically, service0 should be started before
>service1. But I'm starting them with the init.d services in Linux, so that
>can't be guaranteed. The way service1 works is that, upon starting up, it
>will try to connect to service0. If service0 is not running, service1 will
>retry to connect a number of times before giving up and exiting with exit
>code 1.
>
>When it can't connect to service0, service1 prints the following:
>----------------------------------------------------------
>jvm 1    | [ Retrying to connect to 127.0.0.1:1234 ]
>...number of times...
>jvm 1    | [ Retrying to connect to 127.0.0.1:1234 ]
>jvm 1    | [ Retrying to connect to 127.0.0.1:1234 ]
>wrapper  | <-- Wrapper Stopped
>----------------------------------------------------------
>
>So as you see, there's really no unique string it prints out that I can
>trigger on after it failed n times. I found it exits with exit code 1 by
>running the wrapper with logging set to debug.
>Anyway, in theory, at the same time, a different wrapper instance could (in
>my case should) be off starting service0, so I'd like service1's wrapper to
>restart service1 with the hope that service0 will eventually be up to
>connect to. Allowing the wrapper to trigger on service1's exit code would
>help.
>As a workaround (kluge?) , I could just trigger on the "Retrying to connect"
>string, but that would restart after each failed connect, as opposed to
>after the program exits in failure.
>  
>
Good news.  The ability to trigger on a JVM exit code was added in 3.1.0.
Take a look at the docs and let me know if this will do what you need.
http://wrapper.tanukisoftware.org/doc/english/prop-on-exit-n.html

>Another (totally separate) solution would be (and I'm just brainstorming
>here) putting some dependencies on different wrapper applications. Something
>like writing a totally separate script that somehow checks if service0 is
>running (service0 status) before it launches service1...
>  
>
This is available on Windows.   But UNIX does not really provide a 
mechanism to do
this other than specifying startup and shutdown orders in the various 
run levels.

I am always open to great ideas for how to do things.

Cheers,
Leif