PCSK - Process Creation's Swiss-army Knife

PCSK is a program that


The problem

Did you ever have a daemon written in Java (or any other language that does not allow the programmer to access the O/S features needed to daemonise itself)? Did you ever have a poorly written program aimed to be a daemon, but that cannot daemonise itself? Or just written some short script in a hurry that should run as a daemon?


The quick&dirty way was to use the shell to do this kind of work (eg. "someprog &"), with all of its disadvantages. Little better, "nohup someprog &". There's screen also. The right way is using daemontools (supervise, svscan, svc, ..) or run, launchtool, PCSK, or any other program like them.

The 'old way' (using the shell job control, optionally aided with nohup) has many disadvantages. Some of them are:

The daemontools package of D.J. Bernstein is very good, but was too excentric for me (I had the feeling I'm administering the machine turned inside out:-).

The run package of Paul Sheer follows the conventional ways, but misses some features that I need. (eg. logging, pidfile)

So, inspired by the the features of the above two, and some other minor scripts&tricks, was born PCSK, aimed to be the ultimate solution (at least for me:-).

A couple of months ago (it was approx. 2004-06) I discovered another program of the sort. It is the launchtool package of Enrico Zini. Finding it made me very surprised, because it has very similar features to PCSK's (and had realized some of the features still on my TODO list), and I suppose that the same intent led its author in writing his tool as myself. (Which confirmed me that I'm still on the right way.;-). (By the way, his project started just a few weeks after mine. None of us have known of the other's program. Funny, isn't it?:-) About the program: It follows the conventional ways, and has a plethora of useful features; but looking at the code I have a faint feeling that it's main cycle is (algorhytmically) buggy.


The problem

There are programs that should run 24/7. Wouldn't you sleep better if you knew that someone restarts it in place of you.. immediately..?

Of course this works only if the program does not daemonise (not even fork()) itself.


init itself was a program that did this job. But later, with the invention of the "init.d" scripts and "daemonising" (fork & detach) daemons, this feature was sacrificed for the sake of convenience and clarity.

The other tools mentioned in conjunction with daemonising are to be mentioned here as well.

PCSK can do more than init can, as its algorhytm is tunable (behaviour when the service is 'looping').


The problem

You've got a program that should be run every n seconds, must not run two instances at the same time, and is picky about being started in time. What if this program runs (for any reason) for more than n seconds? Yes, it should be started immediately after the previous instace terminated. And what software can do it for you?


Unfortunately cron cannot do this (not even preventing two instances running at the same time - but the latter can be solved by some locking mechanism). With cron and some kind of locking, it is still possible that eg. the program runs a little more than n seconds, and exits a few seconds after the last attempt to start. Then cron will wait almost n seconds (but at least until the beginning of the next minute, even if you are tricky) before starting again.

PCSK can do exactly what is expected in this situation.



Common uses


Because there are..

First of all, the right way for a daemon is to do the daemonisation things itself. No other means give as good results (not even daemontools, run, launchtool or PCSK). Why? Because if the program does itself the fork(), it has the chance to check for some error condition (eg. incorrect configuration file, TCP port already in use, non-existent file, ..), write some diagnostics to stderr and refuse to start. Otherwise the fork()-ing is already done when the program starts, and the program has no way to send a message to the terminal, so the admin can't see immediately (without peeking into the logfile) that the program refused to start.

The "Clean process state" as referenced by D.J. Bernstein cannot be achieved. (Because of the different approach.)




    Copyright (C) 2004  Norbert Buchmuller 

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA


2005-01-09 10:27:25+01
New release (0.0.5). Fixes a bug with option -U.

2004-12-17 22:18+01
New release (0.0.4). Fixes a bug with option -F.

2004-09-01 02:41+02
This page revised, name change (runit -> PCSK) done.

2004-04-16 02:14+02
Rearrangement in the source tree, some documentation added, etc. Version increased without any significant change to pcsk.c.

2004-04-16 03:10+02
Debian package released.

2004-05-12 17:08+02
New version (workaround a bug of getgrouplist() in libc6).

2004-05-12 19:27+02
New version (fixed many severe bugs).


The latest release is 0.0.5.

Older versions available here.

Debian package: here.

NiX | NiX projects | NiX Debian packages | NiX Wiki