New fun tool, procer
- From:
- Zed A. Shaw
- Date:
- 2010-07-28 @ 09:14
So, I ran into a yak and shaved it. I got to the part of the Mongrel
Manual where I describe how you can setup a good deployment. My plan
was to use something like daemontools to get people in the habit of
setting up some kind of automate process manager. Doesn't matter what
it is but daemontools seemed simple.
Whoa, was that wrong. First it doesn't compile, and then it has all
these weird requirements on what a process it supervises should be
doing. Like it can't daemonize. Something that's bread-and-butter to
how a server runs.
I thought, well there's gotta be something out there that isn't idiotic
like this. After trying about 10 different ones I said man this can't
be that hard to make. I could probably make one good enough to manage a
simple Mongrel2 deployment and use in the manual.
And with that, and one day of figuring out how these things work, I
present to you: procer. Just look in examples/procer. The code is dead
simple, and it's actually running the handlers at mongrel2.org right
now. If a handler dies it restarts them, and it starts them up if they
aren't running. Very simple. Throw in a couple seconds wait and it
doesn't thrash your machine on tons of restarts.
You use it like daemontools by just making files in a directory that say
what to do:
profiles/chat/chat.pid
profiles/chat/depends
profiles/chat/pid_file
profiles/chat/restart
profiles/chat/run
That's what's in my chat profile. The pid_file just contains a path to
where this thing will put its pid file. restart is just an empty file,
and if it's there procer will try to restart the thing if it dies. run
is a a shell script that must exit and it should be making pids. If all
you do is say run a regular daemon then you're done. For the chat demos
though they don't daemonize so I just have this:
#!/bin/sh
set -e
cd ~/projects/mongrel2/examples/chat
nohup python chat.py 2>&1 > chat.log &
echo $! > ~/deployment/profiles/chat/chat.pid
So all it's doing is going to the example directory, then having nohup
turn it into a simple daemon like thing, and then making the pid file
for it. Sort of cheap daemons.
All the run scripts have to be executable scripts or they won't run.
It'll complain if they don't.
I have a set of directories for each one, chat, mp3stream, handlertest
and they all start the demos. Then I run procer like this:
procer $PWD/profiles $PWD/run/procer.pid
Right now it's got a bug where it doens't make the pid, but it starts
up, checks to see if all the processes are running, makes sure they are,
then hangs out waiting for them to die.
The only other thing is the depends files. Put a list of other
processes this one needs running before it can start, separated by a
space, all on one line, and procer will make sure those start before
this one starts.
Well, very fun, but I'm probably only going to spend one more day on
procer to fix up some things that make it work and then I'm going to use
it in the manual.
If someone wants to hack on it and make it useful you are free to give
it a try. It's actually got kind of a cool design that uses tasks to
keep track of processes and Rendez waits to manage dependencies. Very
fun.
--
Zed A. Shaw
http://zedshaw.com/