While Foreman is written in Ruby, you don't actually have to use it in any way that is connected to a Ruby or Rails app. All you need is a Procfile and the foreman gem installed on your system.
Then, you can run the processes in the foreground with `foreman start` (eg. on your dev machine), or export the processes to config files for the init system of your choice (eg. on your server). Once the processes have config files in the init system, Foreman is out of the picture: your processes are run and managed by the init system.
Of course, this all works very well in a Rails app (hence my blog post), but that's only one of many uses. Hope that helps!
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.
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.
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:
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.
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.
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.
15 comments
[ 3.2 ms ] story [ 36.6 ms ] threadThen, you can run the processes in the foreground with `foreman start` (eg. on your dev machine), or export the processes to config files for the init system of your choice (eg. on your server). Once the processes have config files in the init system, Foreman is out of the picture: your processes are run and managed by the init system.
Of course, this all works very well in a Rails app (hence my blog post), but that's only one of many uses. Hope that helps!
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.
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.
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.