On 2/6/08, Richard Frovarp <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>  > On 2/6/08, Jörn Nettingsmeier <[EMAIL PROTECTED]> wrote:
>  >> Andreas Hartmann wrote:
>  >>  > I don't know if this behaviour is intended:
>  >>  > When I start my Lenya 1.2.x, the process ID seems to be written to a
>  >>  > file. Ctrl+C doesn't shutdown Jetty, but the next ./lenya.sh kills the
>  >>  > process with the stored ID.
>  >>  >
>  >>  > Is there any special reason for this behaviour? IMO storing PIDs is
>  >>  > dangerous - on the next day, the ID could be assigned to another 
> process
>  >>  > which will be killed when you startup Lenya ... Or is this not 
> possible?
>  >> only if you own it. if you run lenya as a special user (which you really
>  >>  really should), then there's no danger at all. if you run lenya as root,
>  >>  you get what you deserve :)
>  >>
>  >>  storing PIDs is standard behaviour for daemons that are singletons.
>  >>  check the /var/run directory of most unix systems for an overview of how
>  >>  many programs do it...
>  >>  Jörn Nettingsmeier
>  >
>  > I stored the PID to add the "stop" option.  As Jorn states, this is
>  > standard *nix behavior.  The PID being stored is returned from the
>  > java command, not the process calling lenya.sh.  The PID is not stored
>  > when starting in "cli" mode to prevent interfering with a known user
>  > process.  To allow hijacking through reuse of the PID, a user would
>  > need to kill the process without using lenya.sh and find a method to
>  > start a new process on that PID.  I thought the OS always assigns the
>  > PID and has enough PID numbers that I have never seen a rollover.

Clarification: The PID being stored is returned by the java command
starting Java/Jetty/Lenya as a BACKGROUND process.

> It does assign the PID and they do rollover. There's only 32K of them,
>  which isn't too many on some systems. My incoming email systems rollover
>  several times a day, but those are short lived sendmail and various
>  scanning processes.

Most programs needing many short-lived processes use a pool to avoid
the performance hit of creating many new processes.  The performance
hit depends on the threading model; some are optimized so a new
process is faster than a new thread.  I am unaware of a modern MTA
that creates a new process for each message.
[Richard: This is an RFI.  I hate ignorance, especially my own. What
MTA is used?]

>  > Can an OS assign a new Java/Jetty/Lenya process a PID that is already in 
> use?
> No, it shouldn't be able to.

So Lenya killing the process can be a problem if
- The Lenya server process is killed without using lenya.sh or
deleting the PID file.
- Another process is assigned that PID and is still running when
lenya.sh is run again.
- lenya.sh does not verify the PID still belongs to the Lenya server
in that directory.

POTENTIAL SOLUTION: Check if the process about to be killed was
started from this directory.  This code checks that the PID still
refers to a process started from this directory:

LENYA_PID=`cat $LENYA_DIR/lenya.pid`
PID_CMD=`ps -p $LENYA_PID -o cmd --cols 999 --no-headers`
case $PID_CMD in
   *$LENYA_DIR* ) echo "The PID from lenya.pid is for this instance of Lenya."
esac

This works in bash.  The case format for string matching is used
because it does work in ancient sh. I am having difficulty making a
version that will work on zones with its ancient sh because ps does
not support::
   "-o cmd" (Could parse for the CMD column.)
   "--cols 999" or "--columns 999" (Uses environment variable COLUMNS.)
   "--no-headers" (Use loop to check multiple lines?)

[Just saw Andreas' response so stopping this work.]

solprovider

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to