Posts tagged with 'Proclaunch'
Friday, 4 March around 4 o'clock pm
ProcLaunch has learned a bunch of new things lately. I've fixed a few bugs and implemented a few new features, including:
- A
--log-level option, so you can set a level other than DEBUG
- Kill profiles that don't exist
- Instead of killing the process and restarting, proclaunch can send it a signal using the
reload file
- Instead of always sending
SIGTERM, the stop_signal file can contain the name of a signal to send when proclaunch wants to stop a profile
- Pid files are properly cleaned up after processes that don't do it themselves
- You won't get two copies of proclaunch if one is already running as root
Get version 1.1 from github! Thanks a bunch to Matt, who hunted down the bugs and helped me figure out the features.
(Also, I added highlight.js syntax highlighting. Hope you like it!)
Tagged:
Programming
Proclaunch
Read More -
permalink
Thursday, 23 September around 7 o'clock pm
I kind of started ProcLaunch as a lark. Can I actually do better than the existing user space process managers? It turns out that at least a few people think so. I've gotten a ton of great feedback from thijsterlouw, who actually filed bug reports and helped me work through a bunch of issues. ProcLaunch even has some tests now!
As of today, I'm releasing ProcLaunch v1.0, which you can download from the github downloads page. Interesting changes from the initial version:
Moved to an explicit state machine
In the first version there were a lot of edge cases where proclaunch would have a seemingly random sleep, or some other weird thing. I've removed all of the edge cases by creating an explicit state machine. Profiles have a _status() attribute, which is always one of stopped, starting, running, or stopping. The only sleep() is at the end of the main loop.
The main motivation for this change is because the old version was just plain bad design. Every iteration of the main loop woule create a whole new set of Profile objects, overwriting the old list. Awp, but what happens to profiles that should stop? Let's keep track of their pids and keep trying to kill them over and over until they finally die. But what happens if proclaunch dies before those pids die? Do they just live forever, the eternal zombies of a daemon gone wrong?
The new design eliminates both the repeated kill and the overwriting. Now, profiles are kept in a hash keyed on name and are never replaced after creation. Profiles that get stopped are put in the stopping state, which will check up on the pid every second until it finally dies, then moved to stopped, ready to be restarted.
Improved logging
Log lines have a static format: <Timestamp> <Log Level> <Tag> <Message>. <Tag> is either ProcLaunch or the name of the profile. If a message mentiones a pid, it will always be stated as pid <PID>. This change should make it easier to grep through the logs and automatically parse them for monitoring through nagios or what-have-you.
Please check it out and beat it up. If you notice any issues, don't hesitate to submit an issue or email me, or just leave a comment below.
Tagged:
Programming
Proclaunch
Read More -
permalink
Sunday, 1 August around 6 o'clock pm
Modern web applications are complicated beasts. They've got database processes, web serving processes, and various tiers of actual application services. The first two generally take care of themselves. PostgreSQL, MySQL, Apache, Nginx, lighttpd, they all have well-understood ways of starting and keeping themselves up and running.
But what do you do if you have a bunch of processes that you need to keep running that aren't well understood? What if they're well-understood to crash once in a while and you don't want to have to babysit them? You need a user space process manager. Zed Shaw seems to have coined this term specifically for the Mongrel2 manual, and it describes pretty accurately what you'd want: some user-space program running above init that can launch your processes and start them again if they stop. Dropping privilages would be nice. Oh, and it'd be cool if it were sysadmin-friendly. Oh, and if it could automatically detect code changes and restart that'd be nifty too.
Tagged:
Programming
Perl
Proclaunch
Read More -
permalink