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

[Wrapper-user] Out of memory error

[Ashish G. <as...@se...>]

Hi,

I seem to get the following error in my wrapper log and the wrapper 
doesnt seem to restart the JVM.

  [ERROR] ThreadPool - -Caught exception executing 
org.apache.tomcat.util.net.TcpWorkerThread@198fa95f, terminating thread 
<java.lang.OutOfMemoryError>java.lang.OutOfMemoryError

[ERROR] PoolTcpEndpoint - -Unexpected error 
<java.lang.OutOfMemoryError>java.lang.OutOfMemoryError

Any help regarding this would be helpful.
I am running wrapper 2.2.8, and tomcat version 4.1.15 and java 1.3.1

Thank you,

Ashish

Re: [Wrapper-user] I have added support for HP/AIX

[Ashish G. <as...@se...>]

Leif Mortenson wrote:

>  Ashish & William,
>
> Thanks for the patches.  It took me a little while to work through all 
> the changes
> because I had already implemented the ability to daemonize the wrapper 
> as well
> as to set the pid file on all platforms.  Take a look at the new 
> sh.script.in and
> bash.script.in files for examples of how they are used.
>
> I think I got all of your patches implemented correctly but could you 
> please download
> the following source file and try doing the following builds on the 
> AIX and HPUX
> platforms to make sure that they work correctly.
> ./build.sh
> ./build.sh release  ( should create the src and binary releases for 
> the platform )
> ./build.sh clean
> ./build.sh total-clean
>
> You can get your hands on the latest source by doing a CVS checkout.  
> Or if you
> prefer, I placed a copy of the source at the following URL:
> http://www.tanukisoftware.com/wrapper_2.3.0d_src_with_doc_src.tar.gz
>
> Let me know if you find any problems,
> Cheers,
> Leif 

Yoohoo! Tested and works fine on both AIX and HPUX :)

-Ashish

Re: [Wrapper-user] I have added support for HP/AIX

[Ashish G. <as...@se...>]

Leif Mortenson wrote:

>  Ashish & William,
>
> Thanks for the patches.  It took me a little while to work through all 
> the changes
> because I had already implemented the ability to daemonize the wrapper 
> as well
> as to set the pid file on all platforms.  Take a look at the new 
> sh.script.in and
> bash.script.in files for examples of how they are used.
>
> I think I got all of your patches implemented correctly but could you 
> please download
> the following source file and try doing the following builds on the 
> AIX and HPUX
> platforms to make sure that they work correctly.
> ./build.sh
> ./build.sh release  ( should create the src and binary releases for 
> the platform )
> ./build.sh clean
> ./build.sh total-clean
>
> You can get your hands on the latest source by doing a CVS checkout.  
> Or if you
> prefer, I placed a copy of the source at the following URL:
> http://www.tanukisoftware.com/wrapper_2.3.0d_src_with_doc_src.tar.gz
>
> Let me know if you find any problems,
> Cheers,
> Leif
>
I tried on AIX, it works! :)
I dont have a HP-UX machine today, but will test that tomorrow (I dont 
for see any problems!)

-Ashish

Re: [Wrapper-user] I have added support for HP/AIX

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

  Ashish & William,

Thanks for the patches.  It took me a little while to work through all 
the changes
because I had already implemented the ability to daemonize the wrapper 
as well
as to set the pid file on all platforms.  Take a look at the new 
sh.script.in and
bash.script.in files for examples of how they are used.

I think I got all of your patches implemented correctly but could you 
please download
the following source file and try doing the following builds on the AIX 
and HPUX
platforms to make sure that they work correctly.
./build.sh
./build.sh release  ( should create the src and binary releases for the 
platform )
./build.sh clean
./build.sh total-clean

You can get your hands on the latest source by doing a CVS checkout.  Or 
if you
prefer, I placed a copy of the source at the following URL:
http://www.tanukisoftware.com/wrapper_2.3.0d_src_with_doc_src.tar.gz

Let me know if you find any problems,
Cheers,
Leif

Ashish Gawarikar wrote:

> Leif Mortenson wrote:
>
>> Ashish Gawarikar wrote:
>>
>>> But this is in the package 2.2.8 and not in 2.2.9.
>>>
>>> Me and my colleague have also added few bug fixes:
>>> 1. Added run as daemon option for this wrapper to fix the problem 
>>> that the wrapper dies when the shell exits.
>>> 2. clean up the add_srv before binding.
>>>
>>> This has been tested on AIX and HP. I can send the package to the 
>>> Admin/maintainer.
>>>
>>> I did rather send the full tar.gz. Let me know the email id. 
>>
>>
>>
>> Great, please send the source to me directly, not to the list.   I 
>> will look through the changes
>> you made and get them merged in with the trunk.   Once I have done 
>> that, I will ask you to
>> download the patched source again and verify that I did everything 
>> correctly before a release.
>>
>> As to your additional patches:
>> 1) I think that I already got this implemented thanks to a patch by 
>> Rajiv a few days ago.  I would
>> like to see how you implemented it and make and modifications necessary.
>> 2) Could you explain to me what the "add_srv" problem was that you 
>> had been encountering.
>> It may be obvious from the source. 
>
>
> Before doing the bind (in the wrapper.c), the code was not doing a
> memset(&addr_srv, 0, sizeof(addr_srv));
> to clean the addr_srv, as a result I had some problems in the bind. It 
> would always
>
>
> Here I am attaching the source (not a diff). Please let me know if 
> this looks good.
> Thanks,
>
> Ashish Gawarikar
>
> PS: My colleagues name is William Lee.

Re: [Wrapper-user] I have added support for HP/AIX

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

Ashish Gawarikar wrote:

> But this is in the package 2.2.8 and not in 2.2.9.
>
> Me and my colleague have also added few bug fixes:
> 1. Added run as daemon option for this wrapper to fix the problem that 
> the wrapper dies when the shell exits.
> 2. clean up the add_srv before binding.
>
> This has been tested on AIX and HP. I can send the package to the 
> Admin/maintainer.
>
> I did rather send the full tar.gz. Let me know the email id. 

Great, please send the source to me directly, not to the list.   I will 
look through the changes
you made and get them merged in with the trunk.   Once I have done that, 
I will ask you to
download the patched source again and verify that I did everything 
correctly before a release.

As to your additional patches:
1) I think that I already got this implemented thanks to a patch by 
Rajiv a few days ago.  I would
like to see how you implemented it and make and modifications necessary.
2) Could you explain to me what the "add_srv" problem was that you had 
been encountering.
It may be obvious from the source.

Thanks,
Leif

[Wrapper-user] I have added support for HP/AIX

[Ashish G. <as...@se...>]

But this is in the package 2.2.8 and not in 2.2.9.

Me and my colleague have also added few bug fixes:
1. Added run as daemon option for this wrapper to fix the problem that 
the wrapper dies when the shell exits.
2. clean up the add_srv before binding.

This has been tested on AIX and HP. I can send the package to the 
Admin/maintainer.

I did rather send the full tar.gz. Let me know the email id.

THanks,

Ashish Gawarikar

Re: [Wrapper-user] ./wrapper: syntax error at line 1: `(' unexpected

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

jawad bokhari wrote:

>I think you got the problem.
>
>Because I used the precompiled version.
>Now, I'll download the source and then run the
>wrapper.
>
>By the way, what compilers I should have installed on
>my system for that?
>
You will need to have the Sun JDK setup as well as the standard c
compiler which is usually installed by default.

That should be it.

Cheers,
Leif

Re: [Wrapper-user] ./wrapper: syntax error at line 1: `(' unexpected

[jawad b. <bok...@ya...>]

I think you got the problem.

Because I used the precompiled version.
Now, I'll download the source and then run the
wrapper.

By the way, what compilers I should have installed on
my system for that?


Thanks for quick response.

--- Leif Mortenson <le...@ta...> wrote:
> jawad bokhari wrote:
> 
> >Hi support,
> >
> >I am using wrapper for my application server being
> >used in solaris.
> >
> >I think, configuration is ok according to
> >documentation, but still this error comes up on
> >starting wrapper.
> >
> >Even the test application is not run, by giving
> >following command:
> >"./wrapper ../conf/wrapper.conf"
> >
> >Following error comes:
> >
> >"./wrapper: syntax error at line 1: `(' unexpected"
> >
> >Please help, how to get rid of it.
> >
> Jawad,
>  I am not sure what would be causing that.  You are
> running the
> wrapper binary directly rather than using the
> provided sh or bash
> scripts.  That should be fine.
> 
> The error you are getting is coming from the shell. 
> It appears that
> the wrapper binary is corrupted in some way.
> 
> The only idea that I have is that maybe you are
> trying to run the
> linux binary on solaris?   Did you build the wrapper
> from the
> sources?  There is currently not a Solaris binary
> available for
> download.  You have to download one of the source
> distributions and run the provided build scripts.
> I am planning on releasing Solaris builds starting
> with the next
> release again now that I have gotten the SF compile
> farm
> set up correctly.
> 
> Let me know if that doesn't solve the problem and
> I'll try and
> think of something else.
> 
> Cheers,
> Leif
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =
> Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
>
https://lists.sourceforge.net/lists/listinfo/wrapper-user


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Wrapper-user] ./wrapper: syntax error at line 1: `(' unexpected

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

jawad bokhari wrote:

>Hi support,
>
>I am using wrapper for my application server being
>used in solaris.
>
>I think, configuration is ok according to
>documentation, but still this error comes up on
>starting wrapper.
>
>Even the test application is not run, by giving
>following command:
>"./wrapper ../conf/wrapper.conf"
>
>Following error comes:
>
>"./wrapper: syntax error at line 1: `(' unexpected"
>
>Please help, how to get rid of it.
>
Jawad,
 I am not sure what would be causing that.  You are running the
wrapper binary directly rather than using the provided sh or bash
scripts.  That should be fine.

The error you are getting is coming from the shell.  It appears that
the wrapper binary is corrupted in some way.

The only idea that I have is that maybe you are trying to run the
linux binary on solaris?   Did you build the wrapper from the
sources?  There is currently not a Solaris binary available for
download.  You have to download one of the source
distributions and run the provided build scripts.
I am planning on releasing Solaris builds starting with the next
release again now that I have gotten the SF compile farm
set up correctly.

Let me know if that doesn't solve the problem and I'll try and
think of something else.

Cheers,
Leif

[Wrapper-user] ./wrapper: syntax error at line 1: `(' unexpected

[jawad b. <bok...@ya...>]

Hi support,

I am using wrapper for my application server being
used in solaris.

I think, configuration is ok according to
documentation, but still this error comes up on
starting wrapper.

Even the test application is not run, by giving
following command:
"./wrapper ../conf/wrapper.conf"

Following error comes:

"./wrapper: syntax error at line 1: `(' unexpected"

Please help, how to get rid of it.

Thanks,



__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Wrapper-user] wrapper as daemon on un*x

[Rajiv S. <wo...@ya...>]

Hi Leif,
    I apologize for the delayed response.. I will be testing wrapper on solaris
today, and will get back to you in the evening. Can't thank you enough for the
quick response!

Rajiv

--- Leif Mortenson <le...@ta...> wrote:
> Rajiv, Pritchard,
>     Ok, I think I got both the wrapper.daemonize and wrapper.pidfile 
> properties along with
> docs and new versions of the scripts all implemented.   Could you guys 
> please give these
> fixes a try and make sure you agree with the changes.  Also let me know 
> if you have any
> problems/comments with the way this was implemented in the sh/bash 
> template scripts.
> 
>     I decided not to make the wrapper.daemonize property disable output 
> as it did in your
> patch.  This is easy to do by using the wrapper.console.loglevel=NONE 
> property.  This
> way the user will have more control.
> 
>     You can get the source by doing an anonymous checkout from CVS:
> http://sourceforge.net/cvs/?group_id=39428
> 
>     Or, if you rather, I put up a source binary at the following URL. 
>  I'll leave it up for a
> few days:
> http://www.tanukisoftware.com/wrapper_2.3.0b_src_with_doc_src.tar.gz
> 
>     I'm hoping to get a new release out soon.
> 
> Cheers,
> Leif
> 
> 
> Rajiv Subrahmanyam wrote:
> 
> >Hi,
> >   From what i see, when bash exits, it re-assigns all backgrounded
> processes
> >as children of init. The behaviour of sh, (and maybe all other pre-bash
> shells)
> >is to send SIGHUP to all its children, backgrounded or not.. Also, this
> seems
> >to happen only on solaris (aix, maybe), since on (most) linuxii, sh is
> merely a
> >symlink to bash.
> >   Lief, I'm able to see the java processes' output in the log file using
> >daemon mode. I think the stdout and stderr of the java process are being
> >re-assigned.. 
> >I have another question: All the code regarding writing PID files is
> surrounded
> >by #ifdef SOLARIS... I would like to use the PID file mechanism on linux
> too,
> >instead of pidof (Just because i want to use the same bourne sh script with
> >minimum differences between solaris and linux implementations). Is it
> possible
> >to open up that code for both solaris and linux? Thanks!
> >
> >Regards,
> >Rajiv
> >
> >--- "Pritchard, Sean" <SP1...@te...> wrote:
> >  
> >
> >>I am using Solaris 9 and did an explicit test to confirm I was not seeing
> >>Rajiv's reported behavior yesterday.  I am not seeing it, but then again, I
> >>am using bash as my shell and his note said it only occurs when you use sh
> >>as your shell.
> >>
> >>Sean
> >>
> >>-----Original Message-----
> >>From: Leif Mortenson [mailto:le...@ta...]
> >>Sent: Friday, January 17, 2003 12:20 PM
> >>To: wra...@li...
> >>Subject: Re: [Wrapper-user] wrapper as daemon on un*x
> >>
> >>
> >>Rajiv,
> >>Thanks for this patch. But I have some questions.
> >>
> >>I have not had access to a Solaris machine for a while so I can not
> >>verify the
> >>behavior now. On Linux, it appears to work if I telnet to the box, start
> >>an app
> >>and then log off. The wrapper process will still be running when I come
> >>back at
> >>a later date. Maybe this is just a Solaris issue? I am surprised that no
> >>other
> >>users have ever said anything about this before.
> >>
> >>Any solaris users out there have any comments on this?
> >>
> >>I have no problem adding this feature. Especially since it is all
> >>implemented. :-)
> >>I am just curious as to why others have not run into this. Or if they
> >>have, how
> >>they have been working around it.
> >>
> >>Also a question. With this patch. Are you still able to capture stdout
> >>and stderr
> >>output from the Java process and log them to the file. It looks like
> wrapper
> >>console output is being thrown away. Which is fine for a daemon process.
> >>
> >>Cheers,
> >>Leif
> >>
> >>    
> >>
> >
> >__________________________________________________
> >Do you Yahoo!?
> >Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> >http://mailplus.yahoo.com
> >
> >
> >-------------------------------------------------------
> >This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
> >allow you to extend the highest allowed 128 bit encryption to all your 
> >clients even if they use browsers that are limited to 40 bit encryption. 
> >Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> >_______________________________________________
> >Wrapper-user mailing list
> >Wra...@li...
> >https://lists.sourceforge.net/lists/listinfo/wrapper-user
> >
> >  
> >
> 
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

RE: [Wrapper-user] Problems with JRockit

[Martin V. <ma...@ja...>]

Thanks! Both my test application and JBoss work now under both Sun and
JRockit VMs.

I had to use WrapperSimpleApp instead of WrapperStartStopApp, since JBoss'
shutdown class doesn't kill all threads. WrapperSimpleApp makes a clean exit
anyway because JBoss has shutdown hooks which are called when the VM shuts
down with System.exit.

Martin

> -----Original Message-----
> From: wra...@li...
> [mailto:wra...@li...]On Behalf Of Leif
> Mortenson
> Sent: Monday, January 20, 2003 4:34 PM
> To: wra...@li...
> Subject: Re: [Wrapper-user] Problems with JRockit
>
>
> Martin,
>     I started responding before reading all the way to the bottom.  You
> actually
> understand the problem perfectly.
>
>     The Wrapper does the same the thing as the JVM normally does to decide
> when the application is ready to quit.  It counts the active threads.
>  With the IBM
> and Sun JVMs, this list contains a single thread which is started as
> soon as the
> main thread terminates.  I believe this thread then waits for all other
> non daemon
> threads to terminate at which point it calls System.exit.
>     So the Wrapper always wait until there is only 1 other non-daemon
> thread rather
> than 0 to account for that system thread.  It may be that the JRockit
> JVM does not
> work the same way? Most likely that system thread does not show up in
> the thread
> list.
>
>     Assuming that is the case, then I will have to add a special case
> for JRockit so
> it will wait for a thread count of 0 for JRockit and 1 for all other
> JVMs.  The count of
> 1 works for Blackdown, IBM and Sun JVMs.  I have not tried any others.
>
>     Anyway.  I think I fixed the problem  I am now looking at the
> resolved full version
> of the JVM.  If it contains "JRockit" then the system thread count is
> set to 0.
> Otherwise it is set to 1.
>
>     I uploaded a temporary release at the following URL.  It also
> contains several
> other fixes, so take a look at the release notes.  I would like to get a
> new release
> out soon, so please let me know whether or not this fixes your problem.
>  Ie. Make
> sure it works on both Sun and JRockit for your application.  I tested
> the Sun JVM
> here.  But I am going to have to rely on you for the JRockit testing :-)
>
> http://www.tanukisoftware.com/wrapper_2.3.0c_src_with_doc_src.zip
> http://www.tanukisoftware.com/wrapper_win32_2.3.0c.zip
>
> Thanks for the great report.
> Cheers,
> Leif
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Problems with JRockit

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

Martin,
    I started responding before reading all the way to the bottom.  You 
actually
understand the problem perfectly.

    The Wrapper does the same the thing as the JVM normally does to decide
when the application is ready to quit.  It counts the active threads. 
 With the IBM
and Sun JVMs, this list contains a single thread which is started as 
soon as the
main thread terminates.  I believe this thread then waits for all other 
non daemon
threads to terminate at which point it calls System.exit.
    So the Wrapper always wait until there is only 1 other non-daemon 
thread rather
than 0 to account for that system thread.  It may be that the JRockit 
JVM does not
work the same way? Most likely that system thread does not show up in 
the thread
list.

    Assuming that is the case, then I will have to add a special case 
for JRockit so
it will wait for a thread count of 0 for JRockit and 1 for all other 
JVMs.  The count of
1 works for Blackdown, IBM and Sun JVMs.  I have not tried any others.

    Anyway.  I think I fixed the problem  I am now looking at the 
resolved full version
of the JVM.  If it contains "JRockit" then the system thread count is 
set to 0.
Otherwise it is set to 1.

    I uploaded a temporary release at the following URL.  It also 
contains several
other fixes, so take a look at the release notes.  I would like to get a 
new release
out soon, so please let me know whether or not this fixes your problem. 
 Ie. Make
sure it works on both Sun and JRockit for your application.  I tested 
the Sun JVM
here.  But I am going to have to rely on you for the JRockit testing :-)

http://www.tanukisoftware.com/wrapper_2.3.0c_src_with_doc_src.zip
http://www.tanukisoftware.com/wrapper_win32_2.3.0c.zip

Thanks for the great report.
Cheers,
Leif

RE: [Wrapper-user] wrapper as daemon on un*x

[Pritchard, S. <SP1...@te...>]

I'm days away from a major release, so I don't think I'll have time to test
the new version for a while.  
 
Sean

-----Original Message-----
From: Leif Mortenson [mailto:le...@ta...]
Sent: Monday, January 20, 2003 5:39 AM
To: wra...@li...
Subject: Re: [Wrapper-user] wrapper as daemon on un*x


Rajiv, Pritchard,
    Ok, I think I got both the wrapper.daemonize and wrapper.pidfile
properties along with
docs and new versions of the scripts all implemented.   Could you guys
please give these
fixes a try and make sure you agree with the changes.  Also let me know if
you have any
problems/comments with the way this was implemented in the sh/bash template
scripts.

    I decided not to make the wrapper.daemonize property disable output as
it did in your
patch.  This is easy to do by using the wrapper.console.loglevel=NONE
property.  This
way the user will have more control.

    You can get the source by doing an anonymous checkout from CVS:
http://sourceforge.net/cvs/?group_id=39428
<http://sourceforge.net/cvs/?group_id=39428> 

    Or, if you rather, I put up a source binary at the following URL.  I'll
leave it up for a
few days:
http://www.tanukisoftware.com/wrapper_2.3.0b_src_with_doc_src.tar.gz
<http://www.tanukisoftware.com/wrapper_2.3.0b_src_with_doc_src.tar.gz> 

    I'm hoping to get a new release out soon.

Cheers,
Leif


Rajiv Subrahmanyam wrote:


Hi,

   From what i see, when bash exits, it re-assigns all backgrounded
processes

as children of init. The behaviour of sh, (and maybe all other pre-bash
shells)

is to send SIGHUP to all its children, backgrounded or not.. Also, this
seems

to happen only on solaris (aix, maybe), since on (most) linuxii, sh is
merely a

symlink to bash.

   Lief, I'm able to see the java processes' output in the log file using

daemon mode. I think the stdout and stderr of the java process are being

re-assigned.. 

I have another question: All the code regarding writing PID files is
surrounded

by #ifdef SOLARIS... I would like to use the PID file mechanism on linux
too,

instead of pidof (Just because i want to use the same bourne sh script with

minimum differences between solaris and linux implementations). Is it
possible

to open up that code for both solaris and linux? Thanks!



Regards,

Rajiv



--- "Pritchard, Sean"   <mailto:SP1...@te...>
<SP1...@te...> wrote:

  

I am using Solaris 9 and did an explicit test to confirm I was not seeing

Rajiv's reported behavior yesterday.  I am not seeing it, but then again, I

am using bash as my shell and his note said it only occurs when you use sh

as your shell.



Sean



-----Original Message-----

From: Leif Mortenson [ mailto:le...@ta...
<mailto:le...@ta...> ]

Sent: Friday, January 17, 2003 12:20 PM

To:  wra...@li...
<mailto:wra...@li...> 

Subject: Re: [Wrapper-user] wrapper as daemon on un*x





Rajiv,

Thanks for this patch. But I have some questions.



I have not had access to a Solaris machine for a while so I can not

verify the

behavior now. On Linux, it appears to work if I telnet to the box, start

an app

and then log off. The wrapper process will still be running when I come

back at

a later date. Maybe this is just a Solaris issue? I am surprised that no

other

users have ever said anything about this before.



Any solaris users out there have any comments on this?



I have no problem adding this feature. Especially since it is all

implemented. :-)

I am just curious as to why others have not run into this. Or if they

have, how

they have been working around it.



Also a question. With this patch. Are you still able to capture stdout

and stderr

output from the Java process and log them to the file. It looks like wrapper

console output is being thrown away. Which is fine for a daemon process.



Cheers,

Leif



    



__________________________________________________

Do you Yahoo!?

Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

http://mailplus.yahoo.com <http://mailplus.yahoo.com> 





-------------------------------------------------------

This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will

allow you to extend the highest allowed 128 bit encryption to all your 

clients even if they use browsers that are limited to 40 bit encryption. 

Get a guide here: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
<http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en> 

_______________________________________________

Wrapper-user mailing list

Wra...@li...
<mailto:Wra...@li...> 

https://lists.sourceforge.net/lists/listinfo/wrapper-user
<https://lists.sourceforge.net/lists/listinfo/wrapper-user> 



  

[Wrapper-user] Problems with JRockit

[Martin V. <ma...@ja...>]

Hi,

We're running a web application (a multiplayer game) on the JBoss
application server under Windows 2000.

I've been able to successfully run our application in the Wrapper's console
mode using Sun's VM, but it doesn't work with JRockit. The Wrapper version
is 2.2.9.

It looks like the Wrapper kills the application when the first thread that
was started ends. Here's a test application that reproduces the problem:

public class TestStart implements Runnable {

  private static Thread thread;
  static TestStart instance;

  public static void main(String[] args) {
    System.out.println("TestStart: starting thread");
    instance = new TestStart();
    thread = new Thread(instance, "TestStart thread");
    thread.start();
    System.out.println("TestStart: main ending");
  }

  public void run() {
    System.out.println("Thread starting");
    while(!Thread.interrupted()) {
      System.out.println("Running...");
      try {
        Thread.sleep(1000);
      }
      catch(InterruptedException e) {
        break;
      }
    }
    System.out.println("Thread ending");
  }

  public void stop() {
    System.out.println("Stopping thread");
    thread.interrupt();
    try {
      thread.join();
    }
    catch(InterruptedException e) {
      System.out.println("Interrupted waiting for thread to die");
    }
    System.out.println("Thread stopped");
  }
}






#********************************************************************
# Wrapper parameters
#********************************************************************
# Java Application

#wrapper.java.command=/j2sdk1.4.0_01/bin/java
wrapper.java.command=/jrockit/7.0/1.4.0/bin/java

# Java Main class
wrapper.java.mainclass=com.silveregg.wrapper.WrapperStartStopApp

# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=<path to TestStart.class and TestStop.class>

# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=../lib

# Java Additional Parameters
#wrapper.java.additional.1=

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=64

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=512

# Application parameters.  Add parameters as needed starting from 1
wrapper.app.parameter.1=TestStart
wrapper.app.parameter.2=0
wrapper.app.parameter.3=TestStop
wrapper.app.parameter.4=true
wrapper.app.parameter.5=0

# Port which the native wrapper code will attempt to connect to
wrapper.port=1777

#********************************************************************
# Wrapper Logging parameters
#********************************************************************
# Format of output for the console.  (See docs for formats)
wrapper.console.format=PM

# Log Level for console output.  (See docs for log levels)
wrapper.console.loglevel=DEBUG
# INFO

# Log file to use for wrapper output logging.
wrapper.logfile=../logs/wrapper.log

# Format of output for the log file.  (See docs for formats)
wrapper.logfile.format=LPTM

# Log Level for log file output.  (See docs for log levels)
wrapper.logfile.loglevel=INFO

# Maximum size that the log file will be allowed to grow to before
#  the log is rolled. Size is specified in bytes.  The default value
#  of 0, disables log rolling.  May abbreviate with the 'k' (kb) or
#  'm' (mb) suffix.  For example: 10m = 10 megabytes.
wrapper.logfile.maxsize=10m

# Maximum number of rolled log files which will be allowed before old
#  files are deleted.  The default value of 0 implies no limit.
wrapper.logfile.maxfiles=2

# Log Level for sys/event log output.  (See docs for log levels)
wrapper.syslog.loglevel=NONE

#********************************************************************
# Wrapper Unix daemon parameters
#********************************************************************
# File to write process ID to
wrapper.pidfile=/var/run/testwrapper.pid

#********************************************************************
# Wrapper NT Service parameters
#********************************************************************
# WARNING - Do not modify any of these parameters when an application
#  using this configuration file has been installed as a service.
#  Please uninstall the service before modifying this section.  The
#  service can then be reinstalled.

# Name of the service
wrapper.ntservice.name=WrapperTest

# Display name of the service
wrapper.ntservice.displayname=WrapperTest

# Description of the service
wrapper.ntservice.description=WrapperTest

# Service dependencies.  Add dependencies as needed starting from 1
wrapper.ntservice.dependency.1=

# Mode in which the service is installed.  AUTO_START or DEMAND_START
wrapper.ntservice.starttype=AUTO_START

# Priority at which the service is run.  NORMAL, LOW, HIGH, or
#  REALTIME
wrapper.ntservice.process_priority=NORMAL





Here's the output when I run this using Sun's VM:

wrapper  | --> Wrapper Started as Console
wrapperp | server listening on port 1777.
wrapper  | Launching a JVM...
wrapper  | command:
"/j2sdk1.4.0_01/bin/java" -Xms64m -Xmx512m -Djava.library.path="../lib" -cla
sspath
"../lib/wrapper.jar;c:/proj/wrapper_2.2.9_src/build/classes" -Dwrapper.key="
jX9U1ZfVr5KS3Ln6" -Dwrapper.port=1777 -Dwrapper.debug="TRUE" -Dwrapper.cpu.t
imeout="10" -Dwrapper.jvmid=1 com.silveregg.wrapper.WrapperStartStopApp
TestStart 0 TestStop true 0
wrapper  | Java Virtual Machine started (PID=320)
jvm 1    | Wrapper Manager: JVM #1
jvm 1    | Wrapper Manager: Registering shutdown hook
jvm 1    | Wrapper Manager: Using wrapper
jvm 1    | Calling native initialization method.
jvm 1    | Initializing WrapperManager native library.
jvm 1    | Java Executable: C:\j2sdk1.4.0_01\bin\java.exe
jvm 1    | Java Version   : 1.4.0_01-b03 Java HotSpot(TM) Client VM
jvm 1    | Java VM Vendor : Sun Microsystems Inc.
jvm 1    |
jvm 1    | Wrapper (Version 2.2.9)
jvm 1    |
jvm 1    | Open socket to wrapper...
jvm 1    | Opened Socket
jvm 1    | Send a packet 110 : jX9U1ZfVr5KS3Ln6
jvm 1    | handleSocket(Socket[addr=/127.0.0.1,port=1777,localport=1759])
wrapperp | accepted a socket from 127.0.0.1 on port 1759
wrapperp | read a packet 110 : jX9U1ZfVr5KS3Ln6
wrapper  | Got key from JVM: jX9U1ZfVr5KS3Ln6
wrapperp | sent 3 bytes
wrapper  | Start Application.
wrapperp | sent 7 bytes
jvm 1    | Received a packet 112 : 1
jvm 1    | Wrapper Manager: LowLogLevel from Wrapper is 1
jvm 1    | Received a packet 100 : start
jvm 1    | calling listener.start()
jvm 1    | WrapperStartStopApp: start(args)
jvm 1    | WrapperStartStopApp: invoking start main method
jvm 1    | TestStart: starting thread
jvm 1    | TestStart: main ending
jvm 1    | WrapperStartStopApp: start main method completed
jvm 1    | WrapperStartStopApp: start(args) end.  Main Completed=true,
exitCode=null
jvm 1    | returned from listener.start()
jvm 1    | Send a packet 106 :
jvm 1    | Thread starting
jvm 1    | Running...
wrapperp | read a packet 106 :
wrapper  | JVM signalled that it was started.
jvm 1    | Running...
jvm 1    | Running...
wrapperp | sent 6 bytes
jvm 1    | Received a packet 103 : ping
jvm 1    | Send a packet 103 : ok
wrapperp | read a packet 103 : ok
wrapper  | Got ping response from JVM
jvm 1    | Running...
jvm 1    | Running...
jvm 1    | Running...
jvm 1    | Running...



Here's the output when using the JRockit VM. Note that the Wrapper says "All
non-daemon threads have stopped.  Exiting." although our application has
started a thread.


wrapper  | --> Wrapper Started as Console
wrapperp | server listening on port 1777.
wrapper  | Launching a JVM...
wrapper  | command:
"/jrockit/7.0/1.4.0/bin/java" -Xms64m -Xmx512m -Djava.library.path="../lib" 
-classpath
"../lib/wrapper.jar;c:/proj/wrapper_2.2.9_src/build/classes" -Dwrapper.key="
kfsaRmxpL4OAxFrM" -Dwrapper.port=1777 -Dwrapper.debug="TRUE" -Dwrapper.cpu.t
imeout="10" -Dwrapper.jvmid=1 com.silveregg.wrapper.WrapperStartStopApp
TestStart 0 TestStop true 0
wrapper  | Java Virtual Machine started (PID=1404)
jvm 1    | Wrapper Manager: JVM #1
jvm 1    | Wrapper Manager: Registering shutdown hook
jvm 1    | Wrapper Manager: Using wrapper
jvm 1    | Calling native initialization method.
jvm 1    | Initializing WrapperManager native library.
jvm 1    | Java Executable: C:\jrockit\7.0\1.4.0\bin\java.exe
jvm 1    | Java Version   : 1.4.0 BEA Weblogic JRockit(R) Virtual Machine
jvm 1    | Java VM Vendor : BEA Systems, Inc.
jvm 1    |
jvm 1    | Wrapper (Version 2.2.9)
jvm 1    |
jvm 1    | Open socket to wrapper...
jvm 1    | Opened Socket
jvm 1    | Send a packet 110 : kfsaRmxpL4OAxFrM
jvm 1    | handleSocket(Socket[addr=/127.0.0.1,port=1777,localport=1760])
wrapperp | accepted a socket from 127.0.0.1 on port 1760
wrapperp | read a packet 110 : kfsaRmxpL4OAxFrM
wrapper  | Got key from JVM: kfsaRmxpL4OAxFrM
wrapperp | sent 3 bytes
wrapper  | Start Application.
wrapperp | sent 7 bytes
jvm 1    | Received a packet 112 : 1
jvm 1    | Wrapper Manager: LowLogLevel from Wrapper is 1
jvm 1    | Received a packet 100 : start
jvm 1    | calling listener.start()
jvm 1    | WrapperStartStopApp: start(args)
jvm 1    | WrapperStartStopApp: invoking start main method
jvm 1    | TestStart: starting thread
jvm 1    | TestStart: main ending
jvm 1    | WrapperStartStopApp: start main method completed
jvm 1    | WrapperStartStopApp: start(args) end.  Main Completed=true,
exitCode=null
jvm 1    | returned from listener.start()
jvm 1    | Send a packet 106 :
jvm 1    | Thread starting
jvm 1    | Running...
wrapperp | read a packet 106 :
wrapper  | JVM signalled that it was started.
wrapperp | sent 6 bytes
jvm 1    | Received a packet 103 : ping
jvm 1    | Send a packet 103 : ok
jvm 1    | All non-daemon threads have stopped.  Exiting.
jvm 1    | Send a packet 101 : 0
wrapperp | read a packet 103 : ok
wrapper  | Got ping response from JVM
wrapperp | read a packet 101 : 0
wrapper  | JVM requested a shutdown. (0)
wrapper  | wrapperStopProcess(0) called.
wrapper  | Sending stop signal to JVM
wrapperp | sent 2 bytes
jvm 1    | Running...
jvm 1    | Thread, Wrapper-Connection, handling the shutdown process.
jvm 1    | calling listener.stop()
jvm 1    | WrapperStartStopApp: stop(0)
jvm 1    | WrapperStartStopApp: invoking stop main method
jvm 1    | TestStop: main
jvm 1    | Stopping thread
jvm 1    | Thread ending
jvm 1    | Thread stopped
jvm 1    | TestStop: main ending
jvm 1    | WrapperStartStopApp: stop main method completed
jvm 1    | returned from listener.stop()
jvm 1    | Send a packet 107 : 0
jvm 1    | Closing socket.
wrapperp | read a packet 107 : 0
wrapper  | JVM signalled that it was stopped.
wrapperp | socket read no code (closed?).
jvm 1    | calling System.exit(0)
wrapper  | JVM exited normally.
wrapper  | <-- Wrapper Stopped


The problem seems to be in the following code in WrapperManager:

private static void checkThreads() {
  int liveCount = getNonDaemonThreadCount();

  // There will always be one non-daemon thread alive.  This thread is
either the main
  //  thread which has not yet completed, or a thread launched by java when
the main
  //  thread completes whose job is to wait around for all other non-daemon
threads to
  //  complete.  We are overriding that thread here.
  if (liveCount <= 1) {
    if (_debug) {
      System.out.println("All non-daemon threads have stopped.  Exiting.");
    }

    // Exit normally
    WrapperManager.stop(0);
    // Will not get here.
  } else {
      // There are daemons running, let the JVM continue to run.
  }
}

The first comment here might be the key. Perhaps the assumption that there's
always one non-daemon thread alive is JVM specific. I've tried a workaround
to create a dummy thread, making sure that the thread count never falls
below 2. It works, but it would be nice with a cleaner solution.

Any ideas?

Martin Vilcans

Re: [Wrapper-user] wrapper as daemon on un*x

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

Rajiv, Pritchard,
    Ok, I think I got both the wrapper.daemonize and wrapper.pidfile 
properties along with
docs and new versions of the scripts all implemented.   Could you guys 
please give these
fixes a try and make sure you agree with the changes.  Also let me know 
if you have any
problems/comments with the way this was implemented in the sh/bash 
template scripts.

    I decided not to make the wrapper.daemonize property disable output 
as it did in your
patch.  This is easy to do by using the wrapper.console.loglevel=NONE 
property.  This
way the user will have more control.

    You can get the source by doing an anonymous checkout from CVS:
http://sourceforge.net/cvs/?group_id=39428

    Or, if you rather, I put up a source binary at the following URL. 
 I'll leave it up for a
few days:
http://www.tanukisoftware.com/wrapper_2.3.0b_src_with_doc_src.tar.gz

    I'm hoping to get a new release out soon.

Cheers,
Leif


Rajiv Subrahmanyam wrote:

>Hi,
>   From what i see, when bash exits, it re-assigns all backgrounded processes
>as children of init. The behaviour of sh, (and maybe all other pre-bash shells)
>is to send SIGHUP to all its children, backgrounded or not.. Also, this seems
>to happen only on solaris (aix, maybe), since on (most) linuxii, sh is merely a
>symlink to bash.
>   Lief, I'm able to see the java processes' output in the log file using
>daemon mode. I think the stdout and stderr of the java process are being
>re-assigned.. 
>I have another question: All the code regarding writing PID files is surrounded
>by #ifdef SOLARIS... I would like to use the PID file mechanism on linux too,
>instead of pidof (Just because i want to use the same bourne sh script with
>minimum differences between solaris and linux implementations). Is it possible
>to open up that code for both solaris and linux? Thanks!
>
>Regards,
>Rajiv
>
>--- "Pritchard, Sean" <SP1...@te...> wrote:
>  
>
>>I am using Solaris 9 and did an explicit test to confirm I was not seeing
>>Rajiv's reported behavior yesterday.  I am not seeing it, but then again, I
>>am using bash as my shell and his note said it only occurs when you use sh
>>as your shell.
>>
>>Sean
>>
>>-----Original Message-----
>>From: Leif Mortenson [mailto:le...@ta...]
>>Sent: Friday, January 17, 2003 12:20 PM
>>To: wra...@li...
>>Subject: Re: [Wrapper-user] wrapper as daemon on un*x
>>
>>
>>Rajiv,
>>Thanks for this patch. But I have some questions.
>>
>>I have not had access to a Solaris machine for a while so I can not
>>verify the
>>behavior now. On Linux, it appears to work if I telnet to the box, start
>>an app
>>and then log off. The wrapper process will still be running when I come
>>back at
>>a later date. Maybe this is just a Solaris issue? I am surprised that no
>>other
>>users have ever said anything about this before.
>>
>>Any solaris users out there have any comments on this?
>>
>>I have no problem adding this feature. Especially since it is all
>>implemented. :-)
>>I am just curious as to why others have not run into this. Or if they
>>have, how
>>they have been working around it.
>>
>>Also a question. With this patch. Are you still able to capture stdout
>>and stderr
>>output from the Java process and log them to the file. It looks like wrapper
>>console output is being thrown away. Which is fine for a daemon process.
>>
>>Cheers,
>>Leif
>>
>>    
>>
>
>__________________________________________________
>Do you Yahoo!?
>Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
>http://mailplus.yahoo.com
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
>allow you to extend the highest allowed 128 bit encryption to all your 
>clients even if they use browsers that are limited to 40 bit encryption. 
>Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>

Re: [Wrapper-user] wrapper as daemon on un*x

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

#! /bin/sh

#
# Skeleton sh script suitable for starting and stopping 
# wrapped Java apps on the Solaris platform. 
#
# This script expects to find the 'realpath' executable
# in the same directory. 
#
# Make sure that PIDFILE points to the correct location,
# if you have changed the default location set in the 
# wrapper configuration file.
#

#-----------------------------------------------------------------------------
# These settings can be modified to fit the needs of your application

# Application
APP_NAME="@app.name@"
APP_LONG_NAME="@app.long.name@"

# Wrapper
WRAPPER_CMD="./wrapper"
WRAPPER_CONF="../conf/wrapper.conf"

# Priority (see the start() method if you want to use this) 
PRIORITY=

# Do not modify anything beyond this point
#-----------------------------------------------------------------------------

# Get to the actual location of this script
SCRIPT_DIR=`dirname $0`
SCRIPT=`$SCRIPT_DIR/realpath $0`
cd `dirname $SCRIPT`

# Process ID
PIDDIR="/var/run"
PIDFILE="$PIDDIR/$APP_NAME.pid"
pid=""

getpid() {
    if [ -f $PIDFILE ]
    then
    if [ -r $PIDFILE ]
    then
        pid=`cat $PIDFILE`
        if [ "X$pid" != "X" ]
        then
        # Verify that a process with this pid is still running.
        pid=`/usr/bin/ps -p $pid | grep $pid | grep -v grep | awk '{print $1}' | tail -1`
        if [ "X$pid" = "X" ]
        then
            # This is a stale pid file.
            rm -f $PIDFILE
            echo "Removed stale pid file: $PIDFILE"
        fi
        fi
    else
        echo "Cannot read $PIDFILE."
        rm -f $PIDFILE
        exit 1
    fi
    fi
}
 
start() {
    echo "Starting $APP_LONG_NAME..."
    getpid
    if [ "X$pid" = "X" ]
    then
        # If you wanted to specify the priority with which
        # your app runs, you could use nice here:
        # exec nice -$PRIORITY $WRAPPER_CMD $WRAPPER_CONF &
        # See "man nice" for more details.
        exec $WRAPPER_CMD $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.daemonize=true &
    else
        echo "$APP_LONG_NAME is already running."
        exit 1
    fi
}
 
stop() {
    echo "Stopping $APP_LONG_NAME..."
    getpid
    if [ "X$pid" = "X" ]
    then
        echo "$APP_LONG_NAME was not running."

    else
        kill $pid
        sleep 6

        pid=`/usr/bin/ps -p $pid | grep $pid | grep -v grep | awk '{print $1}' | tail -1`

        if [ "X$pid" != "X" ]
        then
        # SIGTERM didn't work, send SIGKILL.
            kill -9 $pid
        rm -f $PIDFILE

            pid=`/usr/bin/ps -p $pid | grep $pid | grep -v grep | awk '{print $1}' | tail -1`
        fi

        if [ "X$pid" != "X" ]
        then
            echo "Failed to stop $APP_LONG_NAME."
            exit 1
        else
            echo "Stopped $APP_LONG_NAME."
        fi
    fi
}

dump() {
    echo "Dumping $APP_LONG_NAME..."
    getpid
    if [ "X$pid" = "X" ]
    then
        echo "$APP_LONG_NAME was not running."

    else
        kill -3 $pid

        if [ $? -ne 0 ]
        then
            echo "Failed to dump $APP_LONG_NAME."
            exit 1
        else
            echo "Dumped $APP_LONG_NAME."
        fi
    fi
}

case "$1" in

    'start')
        start
        ;;

    'stop')
        stop
        ;;

    'restart')
        stop
        start
        ;;

    'dump')
        dump
        ;;

    *)
        echo "Usage: $0 { start | stop | restart | dump }"
        exit 1
        ;;
esac

exit 0

Re: [Wrapper-user] wrapper as daemon on un*x

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

Ok.  Thanks guys.  I think I understand the issue now.

So far I have tried to make it so that a user could create a 
wrapper.conf file which
would work unmodified across all platforms.   If possible,  I would like 
that to continue.
So here is what I would propose.

Modify the functionality of the wrapper.pidfile property so that it will 
always create a
pid file if set, regardless of *nix platform.   Then remove the property 
from the default
wrapper.conf file.

In addition, add a new property wrapper.daemonize which will also always 
daemonize
the wrapper process as per Rajiv's post if set.

While it will still be possible to set these properties in the 
wrapper.conf file,  their
normal use will be to set them from within the .sh script.   bash 
scripts will not set either
one.   By doing it this way, the scripts will work on either platform 
depending on the type
of script that a particular wishes to use.  Furthermore, this will allow 
users to write custom
scripts to get the exact behavior that they wish.

Does that sound like it will solve all the problems?

One drawback is that all *nix users will have to remove the 
wrapper.pidfile property from
their conf files and .sh shell users will have to upgrade to the latest 
version of the script
with their next upgrade.   I'll do some testing as I get this 
implemented to see what
happens in either case if the user omits either of these steps.

Let me know your thoughts.

Cheers,
Leif

Rajiv Subrahmanyam wrote:

>Hi,
>   From what i see, when bash exits, it re-assigns all backgrounded processes
>as children of init. The behaviour of sh, (and maybe all other pre-bash shells)
>is to send SIGHUP to all its children, backgrounded or not.. Also, this seems
>to happen only on solaris (aix, maybe), since on (most) linuxii, sh is merely a
>symlink to bash.
>   Lief, I'm able to see the java processes' output in the log file using
>daemon mode. I think the stdout and stderr of the java process are being
>re-assigned.. 
>I have another question: All the code regarding writing PID files is surrounded
>by #ifdef SOLARIS... I would like to use the PID file mechanism on linux too,
>instead of pidof (Just because i want to use the same bourne sh script with
>minimum differences between solaris and linux implementations). Is it possible
>to open up that code for both solaris and linux? Thanks!
>
>Regards,
>Rajiv
>
>--- "Pritchard, Sean" <SP1...@te...> wrote:
>  
>
>>I am using Solaris 9 and did an explicit test to confirm I was not seeing
>>Rajiv's reported behavior yesterday.  I am not seeing it, but then again, I
>>am using bash as my shell and his note said it only occurs when you use sh
>>as your shell.
>>
>>Sean
>>
>>-----Original Message-----
>>From: Leif Mortenson [mailto:le...@ta...]
>>Sent: Friday, January 17, 2003 12:20 PM
>>To: wra...@li...
>>Subject: Re: [Wrapper-user] wrapper as daemon on un*x
>>
>>
>>Rajiv,
>>Thanks for this patch. But I have some questions.
>>
>>I have not had access to a Solaris machine for a while so I can not
>>verify the
>>behavior now. On Linux, it appears to work if I telnet to the box, start
>>an app
>>and then log off. The wrapper process will still be running when I come
>>back at
>>a later date. Maybe this is just a Solaris issue? I am surprised that no
>>other
>>users have ever said anything about this before.
>>
>>Any solaris users out there have any comments on this?
>>
>>I have no problem adding this feature. Especially since it is all
>>implemented. :-)
>>I am just curious as to why others have not run into this. Or if they
>>have, how
>>they have been working around it.
>>
>>Also a question. With this patch. Are you still able to capture stdout
>>and stderr
>>output from the Java process and log them to the file. It looks like wrapper
>>console output is being thrown away. Which is fine for a daemon process.
>>
>>Cheers,
>>Leif
>>
>>    
>>
>
>__________________________________________________
>Do you Yahoo!?
>Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
>http://mailplus.yahoo.com
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
>allow you to extend the highest allowed 128 bit encryption to all your 
>clients even if they use browsers that are limited to 40 bit encryption. 
>Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>

RE: [Wrapper-user] wrapper as daemon on un*x

[Rajiv S. <wo...@ya...>]

Hi,
   From what i see, when bash exits, it re-assigns all backgrounded processes
as children of init. The behaviour of sh, (and maybe all other pre-bash shells)
is to send SIGHUP to all its children, backgrounded or not.. Also, this seems
to happen only on solaris (aix, maybe), since on (most) linuxii, sh is merely a
symlink to bash.
   Lief, I'm able to see the java processes' output in the log file using
daemon mode. I think the stdout and stderr of the java process are being
re-assigned.. 
I have another question: All the code regarding writing PID files is surrounded
by #ifdef SOLARIS... I would like to use the PID file mechanism on linux too,
instead of pidof (Just because i want to use the same bourne sh script with
minimum differences between solaris and linux implementations). Is it possible
to open up that code for both solaris and linux? Thanks!

Regards,
Rajiv

--- "Pritchard, Sean" <SP1...@te...> wrote:
> I am using Solaris 9 and did an explicit test to confirm I was not seeing
> Rajiv's reported behavior yesterday.  I am not seeing it, but then again, I
> am using bash as my shell and his note said it only occurs when you use sh
> as your shell.
> 
> Sean
> 
> -----Original Message-----
> From: Leif Mortenson [mailto:le...@ta...]
> Sent: Friday, January 17, 2003 12:20 PM
> To: wra...@li...
> Subject: Re: [Wrapper-user] wrapper as daemon on un*x
> 
> 
> Rajiv,
> Thanks for this patch. But I have some questions.
> 
> I have not had access to a Solaris machine for a while so I can not
> verify the
> behavior now. On Linux, it appears to work if I telnet to the box, start
> an app
> and then log off. The wrapper process will still be running when I come
> back at
> a later date. Maybe this is just a Solaris issue? I am surprised that no
> other
> users have ever said anything about this before.
> 
> Any solaris users out there have any comments on this?
> 
> I have no problem adding this feature. Especially since it is all
> implemented. :-)
> I am just curious as to why others have not run into this. Or if they
> have, how
> they have been working around it.
> 
> Also a question. With this patch. Are you still able to capture stdout
> and stderr
> output from the Java process and log them to the file. It looks like wrapper
> console output is being thrown away. Which is fine for a daemon process.
> 
> Cheers,
> Leif
> 

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

RE: [Wrapper-user] wrapper as daemon on un*x

[Pritchard, S. <SP1...@te...>]

I am using Solaris 9 and did an explicit test to confirm I was not seeing
Rajiv's reported behavior yesterday.  I am not seeing it, but then again, I
am using bash as my shell and his note said it only occurs when you use sh
as your shell.

Sean

-----Original Message-----
From: Leif Mortenson [mailto:le...@ta...]
Sent: Friday, January 17, 2003 12:20 PM
To: wra...@li...
Subject: Re: [Wrapper-user] wrapper as daemon on un*x


Rajiv,
Thanks for this patch. But I have some questions.

I have not had access to a Solaris machine for a while so I can not
verify the
behavior now. On Linux, it appears to work if I telnet to the box, start
an app
and then log off. The wrapper process will still be running when I come
back at
a later date. Maybe this is just a Solaris issue? I am surprised that no
other
users have ever said anything about this before.

Any solaris users out there have any comments on this?

I have no problem adding this feature. Especially since it is all
implemented. :-)
I am just curious as to why others have not run into this. Or if they
have, how
they have been working around it.

Also a question. With this patch. Are you still able to capture stdout
and stderr
output from the Java process and log them to the file. It looks like wrapper
console output is being thrown away. Which is fine for a daemon process.

Cheers,
Leif




-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] wrapper as daemon on un*x

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

Rajiv,
Thanks for this patch. But I have some questions.

I have not had access to a Solaris machine for a while so I can not
verify the
behavior now. On Linux, it appears to work if I telnet to the box, start
an app
and then log off. The wrapper process will still be running when I come
back at
a later date. Maybe this is just a Solaris issue? I am surprised that no
other
users have ever said anything about this before.

Any solaris users out there have any comments on this?

I have no problem adding this feature. Especially since it is all
implemented. :-)
I am just curious as to why others have not run into this. Or if they
have, how
they have been working around it.

Also a question. With this patch. Are you still able to capture stdout
and stderr
output from the Java process and log them to the file. It looks like wrapper
console output is being thrown away. Which is fine for a daemon process.

Cheers,
Leif

[Wrapper-user] wrapper as daemon on un*x

[rajiv s. <wo...@ya...>]

Hi guys,

Awesome work.. I do have a few questions/suggestions
regarding the way wrapper runs as a daemon on un*x. It
could be that I have totally misunderstood the
situation, please help me out if that is the case.

The documentation says ' There are not any differences
between running as a service vs as a console
application in a Unix environment.', and looking at
the example sh and bash scripts supplied, the process
is started by putting it in the background (using an
&).

Doing that will work if (and only if) the controlling
terminal does not send the process a SIGHUP. For
example, if you telnet to a solaris host, and the
default login shell of the person you are logging in
as is sh (not bash), and you then su and 
/etc/init.d/script start: the process will be put in
the background, but when you log out, the process WILL
be killed.

However, the way unix startup scripts typically work
is to just execute the process with a flag to tell it
to become a daemon (not backgrounded). The process is
then responsible for forking and putting itself in the
background. 

I made some changes to wrapper_unix.c and started
wrapper with the additional parameter
wrapper.isunixdaemon=true, and it seems to solve the
issue. (I have enclosed my changes within 'Begin
Rajiv's changes' and 'End Rajiv's changes')

I hope I didn't totally miss something.. Again, folks,
great work!

best regards,
Rajiv

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Wrapper-user] wrapper not shutting down on Solaris

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

Sean,
    Glad you got things working.  I made the suggested change.  It will 
be in the next released
version.  Thanks for the feedback.

Here the new text in the conf file:
---
# File to write process ID to.  If you change this value and you are
#  using an sh script to launch the wrapper then you must also update
#  that script.  bash scripts do not require any modification.
wrapper.pidfile=/var/run/@app.name@.pid
---

I also added a comment on this in the documentation:
---
wrapper.pidfile

File to write process ID to. This file is used by sh scripts to make it 
possible to tell whether or not the wrapper process is already running. 
If you modify this parameter and you are using a sh script to control 
the wrapper then please make sure that you make sure you also update the 
script to reflect this change.

Example:
wrapper.pidfile=/var/run/myapp.pid

Text in sh.script which needs to updated:
# Process ID
PIDDIR="/var/run"
PIDFILE="$PIDDIR/$APP_NAME.pid"
---


Cheers,
Leif

Pritchard, Sean wrote:

>I've fixed the problem.  I had changed the location of the pid file in 
>the .conf file but not in the script that starts and stops the program.
>Once I synched the
>two, everything was fine.
>
>I suggest that a comment be added to the conf file warning users that the
>PID file path and name must match that in the startup script.  
>
>I've been quite happy with wrapper.  Thanks for the good product!
>
>Sean
>
>-----Original Message-----
>From: Pritchard, Sean 
>Sent: Thursday, January 09, 2003 2:15 PM
>To: Wrapper User mailing list (E-mail)
>Subject: [Wrapper-user] wrapper not shutting down on Solaris
>
>
>Hi,
>
>	I downloaded the wrapper source and build it on Solaris 9.  I got my
>app up and running with no significant trouble.  But when I went to stop my
>app, I got a message that my app was not running.  I know this wasn't true
>because I could see the process after issueing a "ps" command and because my
>app's log files were continuing to show new messages as the app ran.
>
>	The one change I mad to the conf file that seemed significant to
>this problem is I set "wrapper.pidfile=./multiplexer.pid"  I did this
>because I did not have write permissions to the directory that is set by
>default.  I can see the .pid file being created and it contains the correct
>process ID.  When I manually stop the app with the kill command, the .pid
>file is deleted.  So I conclude from this that wrapper is finding the file
>without problem.  I use a script based on testwrapper to start and stop the
>app.  I only changes the app name, app long name, and conf file location,
>and the shebang to reflect my location of sh.
>
>	I turned on debug logging and watched the JVM log a series of pings
>and responses.  So it seems wrapper was successfully monitoring the VM.
>These pings continued after I attempted to stop the app.  A snippet of the
>console output is show below.  My in-line comments start with "//"  I
>inserted whitespace for readability.
>
>	Can anyone suggest what I should do to continue troubleshooting
>this?  I'm at a loss.  BTW, I successfully built on RedHat linux and did not
>encounter this problem.
>
>Thanks in advance,
>Sean
>
>
>jvm 1    | Send a packet 103 : ok
>
>//now I try to stop the app (using my script that is based on testwrapper)
>
>bash-2.05$ ./multiplexer.sh stop
>Stopping Teradata CRM Email Multiplexer...
>Teradata CRM Email Multiplexer was not running.
>
>//my app did not stop, pings continue
>
>bash-2.05$ jvm 1    | Received a packet 103 : ping
>jvm 1    | Send a packet 103 : ok
>
>// I check ps to confirm the app is still running
>
>bash-2.05$ ps -eaf | grep multiplexer
>sp180007 29584 26899  0 13:54:07 pts/5    0:00 grep multiplexer
>sp180007 29562     1  0 13:53:28 pts/5    0:00 ./wrapper
>../config/multiplexer.conf
>bash-2.05$ jvm 1    | Received a packet 103 : ping
>jvm 1    | Send a packet 103 : ok
>
>//it is still running and pinging 
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>

RE: [Wrapper-user] wrapper not shutting down on Solaris

[Pritchard, S. <SP1...@te...>]

I've fixed the problem.  I had changed the location of the pid file in 
the .conf file but not in the script that starts and stops the program.
Once I synched the
two, everything was fine.

I suggest that a comment be added to the conf file warning users that the
PID file path and name must match that in the startup script.  

I've been quite happy with wrapper.  Thanks for the good product!

Sean

-----Original Message-----
From: Pritchard, Sean 
Sent: Thursday, January 09, 2003 2:15 PM
To: Wrapper User mailing list (E-mail)
Subject: [Wrapper-user] wrapper not shutting down on Solaris


Hi,

	I downloaded the wrapper source and build it on Solaris 9.  I got my
app up and running with no significant trouble.  But when I went to stop my
app, I got a message that my app was not running.  I know this wasn't true
because I could see the process after issueing a "ps" command and because my
app's log files were continuing to show new messages as the app ran.

	The one change I mad to the conf file that seemed significant to
this problem is I set "wrapper.pidfile=./multiplexer.pid"  I did this
because I did not have write permissions to the directory that is set by
default.  I can see the .pid file being created and it contains the correct
process ID.  When I manually stop the app with the kill command, the .pid
file is deleted.  So I conclude from this that wrapper is finding the file
without problem.  I use a script based on testwrapper to start and stop the
app.  I only changes the app name, app long name, and conf file location,
and the shebang to reflect my location of sh.

	I turned on debug logging and watched the JVM log a series of pings
and responses.  So it seems wrapper was successfully monitoring the VM.
These pings continued after I attempted to stop the app.  A snippet of the
console output is show below.  My in-line comments start with "//"  I
inserted whitespace for readability.

	Can anyone suggest what I should do to continue troubleshooting
this?  I'm at a loss.  BTW, I successfully built on RedHat linux and did not
encounter this problem.

Thanks in advance,
Sean


jvm 1    | Send a packet 103 : ok

//now I try to stop the app (using my script that is based on testwrapper)

bash-2.05$ ./multiplexer.sh stop
Stopping Teradata CRM Email Multiplexer...
Teradata CRM Email Multiplexer was not running.

//my app did not stop, pings continue

bash-2.05$ jvm 1    | Received a packet 103 : ping
jvm 1    | Send a packet 103 : ok

// I check ps to confirm the app is still running

bash-2.05$ ps -eaf | grep multiplexer
sp180007 29584 26899  0 13:54:07 pts/5    0:00 grep multiplexer
sp180007 29562     1  0 13:53:28 pts/5    0:00 ./wrapper
../config/multiplexer.conf
bash-2.05$ jvm 1    | Received a packet 103 : ping
jvm 1    | Send a packet 103 : ok

//it is still running and pinging 



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

[Wrapper-user] wrapper not shutting down on Solaris

[Pritchard, S. <SP1...@te...>]

Hi,

	I downloaded the wrapper source and build it on Solaris 9.  I got my
app up and running with no significant trouble.  But when I went to stop my
app, I got a message that my app was not running.  I know this wasn't true
because I could see the process after issueing a "ps" command and because my
app's log files were continuing to show new messages as the app ran.

	The one change I mad to the conf file that seemed significant to
this problem is I set "wrapper.pidfile=./multiplexer.pid"  I did this
because I did not have write permissions to the directory that is set by
default.  I can see the .pid file being created and it contains the correct
process ID.  When I manually stop the app with the kill command, the .pid
file is deleted.  So I conclude from this that wrapper is finding the file
without problem.  I use a script based on testwrapper to start and stop the
app.  I only changes the app name, app long name, and conf file location,
and the shebang to reflect my location of sh.

	I turned on debug logging and watched the JVM log a series of pings
and responses.  So it seems wrapper was successfully monitoring the VM.
These pings continued after I attempted to stop the app.  A snippet of the
console output is show below.  My in-line comments start with "//"  I
inserted whitespace for readability.

	Can anyone suggest what I should do to continue troubleshooting
this?  I'm at a loss.  BTW, I successfully built on RedHat linux and did not
encounter this problem.

Thanks in advance,
Sean


jvm 1    | Send a packet 103 : ok

//now I try to stop the app (using my script that is based on testwrapper)

bash-2.05$ ./multiplexer.sh stop
Stopping Teradata CRM Email Multiplexer...
Teradata CRM Email Multiplexer was not running.

//my app did not stop, pings continue

bash-2.05$ jvm 1    | Received a packet 103 : ping
jvm 1    | Send a packet 103 : ok

// I check ps to confirm the app is still running

bash-2.05$ ps -eaf | grep multiplexer
sp180007 29584 26899  0 13:54:07 pts/5    0:00 grep multiplexer
sp180007 29562     1  0 13:53:28 pts/5    0:00 ./wrapper
../config/multiplexer.conf
bash-2.05$ jvm 1    | Received a packet 103 : ping
jvm 1    | Send a packet 103 : ok

//it is still running and pinging