[Supervisor-users] Controlling daemonized programs?

[Josh Jore]

Hi,
I have a daemonized Apache httpd which I'd like to manage with supervisord. I've just read http://supervisord.org/subprocess.html#apache-2-2-6 and http://smarden.org/runit/runscripts.html#apache2 which roughly suggest using -DFOREGROUND to prevent forking and detaching from the console.

I'm really unsure that it's smart for me to adjust this existing daemon much since it's actually a mod_perl application server with a lot of moving parts. I'd much rather just manage the program as-is, even though it detaches from its parent and is a proper daemon.

I'd like a suggestion for something that's been already worked out, preferably nicer than this terribly buggy shell script I just penned for this email.

#!/bin/sh
# TODO(jjore): handle `start | stop | status | restart`
PIDFILE=$1
SIGNAL=WINCH

if [ -r "$PIDFILE" ] && kill -0 $(cat "$PIDFLE"); then
echo "$@ is already running"
exit 1
fi

trap 'kill "-$SIGNAL" $(cat "$PIDFILE")' TERM
rm -f "$PIDFILE"
while true; do
# TODO(jjore): Avoid restarting too quickly
( exec "$@" ) &
while kill -0 $(cat "$PIDFILE") && sleep 1; do
done
wait
done

[David Birdsong]

On Sun, Dec 22, 2013 at 8:58 AM, Josh Jore <***@marchex.com> wrote:

> Hi,
> I have a daemonized Apache httpd which I'd like to manage with
> supervisord. I've just read
> http://supervisord.org/subprocess.html#apache-2-2-6 and
> http://smarden.org/runit/runscripts.html#apache2 which roughly suggest
> using -DFOREGROUND to prevent forking and detaching from the console.
>
> I'm really unsure that it's smart for me to adjust this existing daemon
> much since it's actually a mod_perl application server with a lot of moving
> parts. I'd much rather just manage the program as-is, even though it
> detaches from its parent and is a proper daemon.
>
>
These two paragraphs contradict each other to some extent. 1. you'd like to
manage w/ supervisord, then 2nd states that there's too much going on w/
the app to get it to behave under supervisord.

My suggestion is to identify what you want out of supervisord that the
apache package scripts doesn't provide. If it's just the ability to expose
the status and restart commands over a cli, then let me introduce you to
(ba)sh/csh/zsh--also considered CLI's.



> I'd like a suggestion for something that's been already worked out,
> preferably nicer than this terribly buggy shell script I just penned for
> this email.
>
> #!/bin/sh
> # TODO(jjore): handle `start | stop | status | restart`
> PIDFILE=$1
> SIGNAL=WINCH
>
> if [ -r "$PIDFILE" ] && kill -0 $(cat "$PIDFLE"); then
> echo "$@ is already running"
> exit 1
> fi
>
> trap 'kill "-$SIGNAL" $(cat "$PIDFILE")' TERM
> rm -f "$PIDFILE"
> while true; do
> # TODO(jjore): Avoid restarting too quickly
> ( exec "$@" ) &
> while kill -0 $(cat "$PIDFILE") && sleep 1; do
> done
> wait
> done
>
>
>
I'd avoid any of this voodoo. You're reinventing what supervisord
offers--process control by way of the WAIT variants.

Some processes come with a good set of daemonization primitives that
working around aren't worth the effort. Supervisord offers process control
for processes missing these primitives.

For me: nginx and haproxy are the two I never run under anything under init
or upstart. There's so much going on with graceful reloads and child
watching that supervisord (or circusd) aren't needed and create extra work
for me. the operator, for little benefit.



> _______________________________________________
> Supervisor-users mailing list
> Supervisor-***@lists.supervisord.org
> https://lists.supervisord.org/mailman/listinfo/supervisor-users
>
>

[Josh Jore]

What I'm getting is clean and unified management of this and some other related daemons. It seems reasonable to allow supervisord to manage details like ensuring restarts if/when the daemon isn't running, handling start/stop in a common way, etc.

There's a lot more to supervisord than just managing things that have a console.

J

________________________________
From: David Birdsong [***@gmail.com]
Sent: Sunday, December 22, 2013 1:35 PM
To: Josh Jore
Cc: supervisor-***@lists.supervisord.org
Subject: Re: [Supervisor-users] Controlling daemonized programs?




On Sun, Dec 22, 2013 at 8:58 AM, Josh Jore <***@marchex.com<mailto:***@marchex.com>> wrote:
Hi,
I have a daemonized Apache httpd which I'd like to manage with supervisord. I've just read http://supervisord.org/subprocess.html#apache-2-2-6 and http://smarden.org/runit/runscripts.html#apache2 which roughly suggest using -DFOREGROUND to prevent forking and detaching from the console.

I'm really unsure that it's smart for me to adjust this existing daemon much since it's actually a mod_perl application server with a lot of moving parts. I'd much rather just manage the program as-is, even though it detaches from its parent and is a proper daemon.


These two paragraphs contradict each other to some extent. 1. you'd like to manage w/ supervisord, then 2nd states that there's too much going on w/ the app to get it to behave under supervisord.

My suggestion is to identify what you want out of supervisord that the apache package scripts doesn't provide. If it's just the ability to expose the status and restart commands over a cli, then let me introduce you to (ba)sh/csh/zsh--also considered CLI's.


I'd like a suggestion for something that's been already worked out, preferably nicer than this terribly buggy shell script I just penned for this email.

#!/bin/sh
# TODO(jjore): handle `start | stop | status | restart`
PIDFILE=$1
SIGNAL=WINCH

if [ -r "$PIDFILE" ] && kill -0 $(cat "$PIDFLE"); then
echo "$@ is already running"
exit 1
fi

trap 'kill "-$SIGNAL" $(cat "$PIDFILE")' TERM
rm -f "$PIDFILE"
while true; do
# TODO(jjore): Avoid restarting too quickly
( exec "$@" ) &
while kill -0 $(cat "$PIDFILE") && sleep 1; do
done
wait
done



I'd avoid any of this voodoo. You're reinventing what supervisord offers--process control by way of the WAIT variants.

Some processes come with a good set of daemonization primitives that working around aren't worth the effort. Supervisord offers process control for processes missing these primitives.

For me: nginx and haproxy are the two I never run under anything under init or upstart. There's so much going on with graceful reloads and child watching that supervisord (or circusd) aren't needed and create extra work for me. the operator, for little benefit.

[David Birdsong]

On Sun, Dec 22, 2013 at 11:50 PM, Josh Jore <***@marchex.com> wrote:

> What I'm getting is clean and unified management of this and some other
> related daemons. It seems reasonable to allow supervisord to manage details
> like ensuring restarts if/when the daemon isn't running, handling
> start/stop in a common way, etc.
>
>
Forgive me, it's been ages since I've run Apache. Does it not have a parent
proc that manages it's children and handle restarts for any children that
crash due to runtime bugs in various modules: mod_php, mod_perl, cgi..etc?

Restarts are certainly a big part of supervisord, but I'd be wary of
reinventing it w/ a shell script that sources PID files and verifies the
PID against running PIDs or tries to catch signals. Make no mistake, if you
have a loop in a shell script hanging off of supervisord that checks a proc
status, then you've reinvented much of it's functionality.

Perhaps instead of making a wrapper that indirectly supervises the Apache
PID, you could write a 'daemon' that performs local health checks against a
URL and calls the packaged scripts to restart if certain conditions are
unmet.

There's a lot more to supervisord than just managing things that have a
> console.
>
> J
>
> ------------------------------
> *From:* David Birdsong [***@gmail.com]
> *Sent:* Sunday, December 22, 2013 1:35 PM
> *To:* Josh Jore
> *Cc:* supervisor-***@lists.supervisord.org
> *Subject:* Re: [Supervisor-users] Controlling daemonized programs?
>
>
>
>
> On Sun, Dec 22, 2013 at 8:58 AM, Josh Jore <***@marchex.com> wrote:
>
>> Hi,
>> I have a daemonized Apache httpd which I'd like to manage with
>> supervisord. I've just read
>> http://supervisord.org/subprocess.html#apache-2-2-6 and
>> http://smarden.org/runit/runscripts.html#apache2 which roughly suggest
>> using -DFOREGROUND to prevent forking and detaching from the console.
>>
>> I'm really unsure that it's smart for me to adjust this existing daemon
>> much since it's actually a mod_perl application server with a lot of moving
>> parts. I'd much rather just manage the program as-is, even though it
>> detaches from its parent and is a proper daemon.
>>
>>
> These two paragraphs contradict each other to some extent. 1. you'd like
> to manage w/ supervisord, then 2nd states that there's too much going on w/
> the app to get it to behave under supervisord.
>
> My suggestion is to identify what you want out of supervisord that the
> apache package scripts doesn't provide. If it's just the ability to expose
> the status and restart commands over a cli, then let me introduce you to
> (ba)sh/csh/zsh--also considered CLI's.
>
>
>
>> I'd like a suggestion for something that's been already worked out,
>> preferably nicer than this terribly buggy shell script I just penned for
>> this email.
>>
>> #!/bin/sh
>> # TODO(jjore): handle `start | stop | status | restart`
>> PIDFILE=$1
>> SIGNAL=WINCH
>>
>> if [ -r "$PIDFILE" ] && kill -0 $(cat "$PIDFLE"); then
>> echo "$@ is already running"
>> exit 1
>> fi
>>
>> trap 'kill "-$SIGNAL" $(cat "$PIDFILE")' TERM
>> rm -f "$PIDFILE"
>> while true; do
>> # TODO(jjore): Avoid restarting too quickly
>> ( exec "$@" ) &
>> while kill -0 $(cat "$PIDFILE") && sleep 1; do
>> done
>> wait
>> done
>>
>>
>>
> I'd avoid any of this voodoo. You're reinventing what supervisord
> offers--process control by way of the WAIT variants.
>
> Some processes come with a good set of daemonization primitives that
> working around aren't worth the effort. Supervisord offers process control
> for processes missing these primitives.
>
> For me: nginx and haproxy are the two I never run under anything under
> init or upstart. There's so much going on with graceful reloads and child
> watching that supervisord (or circusd) aren't needed and create extra work
> for me. the operator, for little benefit.
>
>
>
>> _______________________________________________
>> Supervisor-users mailing list
>> Supervisor-***@lists.supervisord.org
>> https://lists.supervisord.org/mailman/listinfo/supervisor-users
>>
>>
>

[Jens Rantil]

Hi Josh,

I'll chime in with my 5 cents;

On Mon, Dec 23, 2013 at 8:50 AM, Josh Jore <***@marchex.com> wrote:

> What I'm getting is clean and unified management of this and some other
> related daemons.
>

Instead of reinventing the wheel here, you could also consider having a
look at Ansible/SaltStack or other "configuration" management system. This
would give you the possibility to orchestrate all processes under a unified
interface, without caring about how they are being executed/started/stopped.

Just an idea,
Jens