

Run Your Own Piece of Heroku with Foreman - timriley
http://icelab.com.au/articles/run-your-own-piece-of-heroku-with-foreman/

======
pie
As someone running 5 server processes in development for one project, this
hugely simplifies all the terminal juggling on my local box, and centralizes
the associated commands as part of the codebase. It's a little like a "bundler
for processes!"

There appear to be a few kinks to be worked out; for example Foreman fails to
kill off Redis (for me) as described in this closed bug report:

<https://github.com/ddollar/foreman/issues/15>

Not a huge deal though. I'm happy to be using it for development.

~~~
ddollar
If you try the latest foreman it should be a lot better about killing things
off now. See other comments in this thread about the SIGTERM-pause-SIGKILL
approach.

------
mnutt
Foreman is especially fantastic for development environments. In past projects
our different services and daemons have always either been started ad-hoc, or
by some awful bash script. This lets new team members get up and running
really quickly.

I'd also like to try using it to generate server configs, but I still don't
like what Monit makes you do in order to run a non-daemonized process. I'm not
sure why it can't just daemonize the process for you.

------
cturner
If you kill foreman, will it kill all the processes that that foreman instance
spawned? If so, how does it do this - with process groups?

~~~
ddollar
Yes. If you kill foreman with Ctrl-C (or killing its pid externally) it will
send SIGTERM to all of the child processes, followed 3 seconds later by
SIGKILL to any that haven't terminated yet.

~~~
cturner
OK. But if those processes have spawned further children, then I expect
they'll get isolated and keep running, now with PPID 0 (on linux, anyway).

I have need for a tool that has the ability to kill not just one level of
child processes, but the tree. I've built something similar to foreman
recently and came up with a hacky way to do this tree kill.

Every now and then my tool runs ps and parses the output. It uses PID and PPID
to build a hierarchy of processes that are descended from it. I have a signal
handler in the foreman-like tool that does the SIGTERM then SIGKILL like you
describe. It's ugly and not portable but it is working in my setting.

Since then I've heard about process groups and have been meaning to try that
as an alternate mechanism.

Something foreman has that my python tool doesn't have and that I want is the
ability to bounce processes within the tree.

I'd like to be able to throw away my code and replace it with something
polished. Interested in any further thoughts you have.

Update: hey - you're the author! Thanks. Another feature I'd like is the
ability to query the foreman process running in the background and have it
tell me what stuff it's currently running. The approach I've used in my tool
was to use python-twisted to host a command line, and then I'd telnet to that
and poke it. But - as I say above - it's still missing key features.

------
jackolas
I can't seem to figure out if this is ruby-centric (like Rake) or ruby-only.

~~~
dannytatom
As far as I know you can run anything with it, not just ruby apps.

~~~
timriley
Yes, this is absolutely right. The commands in your Procfile don't have to be
rake tasks, they can be any executable system command.

------
tectonic
How would I tie this in with monit? Would I no longer need monit?

~~~
timriley
The configs that Foreman generates for upstart or standard init system include
the 'respawn' keyword, which makes sure that these processes are restarted if
they crash for any reason. In this way, it can replace monit's basic
functionality. What's not there at the moment is a way of restarting the
processes when they, for example, use too much memory or CPU. Ideally you'd
have something check for this as well.

~~~
ddollar
You could also check out something like
<http://upstart.ubuntu.com/wiki/Stanzas#limit> for use in your upstart
scripts.

~~~
timriley
Ah, that's very useful! Thanks for the heads up.

