On Sun, Dec 22, 2013 at 11:50 PM, Josh Jore <jj...@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 [david.birds...@gmail.com] > *Sent:* Sunday, December 22, 2013 1:35 PM > *To:* Josh Jore > *Cc:* supervisor-users@lists.supervisord.org > *Subject:* Re: [Supervisor-users] Controlling daemonized programs? > > > > > On Sun, Dec 22, 2013 at 8:58 AM, Josh Jore <jj...@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-users@lists.supervisord.org >> https://lists.supervisord.org/mailman/listinfo/supervisor-users >> >> >
_______________________________________________ Supervisor-users mailing list Supervisor-users@lists.supervisord.org https://lists.supervisord.org/mailman/listinfo/supervisor-users
