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
>
>  
>