Hi All,
I run pound on Redhat AS 3.0.
Would like to know the best / recommend method to
stop pound.
Is it just kill the process id? or there is a better way?
Also, I notice that if I stop pound by killing the process id,
the pid file in /var/run didn't get removed, a new pid file will
be generated when I start pound, hence end up a lot of pid
files in /var/run, it makes it hard to keep track which pid file
to use for stopping, should I remove the pid file after
killing the process?

Any comment and suggestion are welcome,
thanks

> Hi All,[...]

You may want to have a look at my rpms which care for such things.

http://www.invoca.ch/pub/packages/pound/

Simon
[...]

Hi Simon,
Thanks for your reply and I will download and check it out.
Cheers...


simon.matter(at)ch.sauter-bc.com wrote:
[...][...]

Hello,

under Debian Linux, I'm using the following hack to circumvent the PID file
issue in /etc/init.d/pound-xxxxx:

----8<----
...
PIDFILE=/var/run/pound-xxxxx.pid

test -x $DAEMON || exit 0

set -e

case "$1" in
  start)
        echo -n "Starting $DESC: $NAME"
        start-stop-daemon --start --quiet --exec /sbin/pound -f
/usr/local/etc/xxxxx.cfg
        mv `ls -1tr /var/run/pound_pid.* | tail -1` $PIDFILE
        echo "."
        ;;
  stop)
        echo -n "Stopping $DESC: $NAME "
        start-stop-daemon --stop --pidfile $PIDFILE --exec /sbin/pound
        rm $PIDFILE
...
----8<----

Clearly, it would be better for pound to write the PID file directly into a
configurable location, maybe using a -p or --pid <file> command line
switch
or config file parameter ("PidFile /var/run/my-pid-file"). Really no big
change, but much safer than indirect approaches like mine above.

Regards,
Matthias




-----Ursprüngliche Nachricht-----
Von: Allan Lee [mailto:allansclee(at)netscape.net]
Gesendet: Montag, 17. Januar 2005 19:16
An: pound(at)apsis.ch
Betreff: Stopping pound and managing pid files


Hi All,
I run pound on Redhat AS 3.0.
Would like to know the best / recommend method to
stop pound.
Is it just kill the process id? or there is a better way?
Also, I notice that if I stop pound by killing the process id, the pid file
in /var/run didn't get removed, a new pid file will be generated when I
start pound, hence end up a lot of pid files in /var/run, it makes it hard
to keep track which pid file to use for stopping, should I remove the pid
file after killing the process?

Any comment and suggestion are welcome,
thanks

Allan Lee wrote:
[...]
this rock-solid and easy-to-manage.  daemontools is the same supervisor 
used by qmail so it has been proven to be very robust, scalable, and secure.

# add the pound service to be supervised (one-time only)
svc-add /var/svc.d/pound

# start pound (one-time only, or after you stop pound for any reason)
svc-start pound

# stop pound
svc-stop pound

# restart pound
svc-restart pound

By using daemontools to supervise pound instead of the built-in one, I 
don't have to track PID.  I still use xinetd for some services, but find 
daemontools much more robust and better for managing pound.

More info:

http://cr.yp.to/daemontools.html
              - daemontools home
http://untroubled.org/supervise-scripts/
    - svc-add, svc-start, 
svc-stop, ... scripts
http://www.thedjbway.org

On Mon, 17 Jan 2005 18:16:23 +0000, Allan Lee
<allansclee(at)netscape.net> wrote:[...]

You can use "killall pound", this will send a signal 15 to all running
pound processes.
It works for me.

--
Met vriendelijke groet / With kind regards,

H. van Wees
---
The official Gentoo motto is, "If it moves, compile it."

Thank you so much for all the replies, appreciated.
Combining the four solutions provided by you guys
I am able to manage the start/stop.
I have a further challenge, trying to use Veritas VCS
to control and monitor Pound for HA fail over.
VCS is looking for a single static pid file to look for the running
process ID. So the pound_pid.nnn file name kinda complicated matter.
I understand why there is a .nnn in the PID file name, so I will have
to find a work round.

Thanks again.

hvwees(at)gmail.com wrote:
[...][...][...]
--