NAME

orphand - Orphan Process Killer

SYNOPSIS

orphand

See client.pl for an example client written in Perl. It spawns several children, then dies. orphand reaps them during its next sweep

DESCRIPTION

orphand attempts to act as a simple daemon which monitors children of spawners. Simply tell orphand (via a Unix socket) about which proceeses should be killed off when a given other process dies, and orphand will comply.

orphand will have no dependencies outside of the normal facilities provided by POSIX.

It is intended to be extremely light weight and extremely reliable. Considering this is a first release, i doubt its reliability.

orphand is meant to provide an extra safety net if having lingering orphan processes is a huge cost (generally because those processes may be using up valuable local (CPU,RAM,I/O) resources, and even worse, global resources (TCP connections).

It would be nice if orphand was able to automatically handle grandchildren, but this would involve using ptrace(2) and a whole other can of worms. Generally just dealing with child processes should be easy enough.

SECURITY

In its current state, orphand is not secure, what this means is that any process has the ability to tell orphand to terminate any other process when any other arbitrary process terminates. Effectively making it an open proxy for kill(2).

While I do plan to make some kinds of basic sanity checks about how orpahnd decides what is and is not a valid request, it is by no means suited for a multi-user environment.

While the above should be obvious, it is just a disclaimer.

Additionally, oprhand gets its state information via polling. Until orphand is implemnted as a kernel module (and I plan for this to happen one day), there is a slight possibility that the PID which was registered as a child would have died, and a different, unrelated process would have spawned with the same PID. While this is highly unlikely, it is certainly a risk, and certainly producable if malicious intent is involved.

As an attempt to alleviate the possibility of orphand killing the wrong process with the same registration number, orphand checks the creation time of each process

GOODIES

There is also a library orphand-forkwait.so intended to be used as a LD_PRELOAD injection, as so

LD_PRELOAD=/path/to/orphand-forkwait.so program

You may also specify the path to the socket for the library by setting ORPHAND_SOCKET in the environment.

The library works by overriding calls to fork(2), waitpid(2) and wait(2) with variants that register and unregister PIDs, as appropriate. Using this library eliminates the need to re-write an application in order to notify orphand about its process events.

The library then calls the 'next' real version of the system call, and for this it relies on being able to find the system's C library, currently hard-coded as libc.so.6. It should be changed to suit your platform's needs (i think it's libSystem.dylib on darwin, for example).

MESSAGES

orphand communicates over unix domain stream sockets. The message format is as follows (this might change, but considering the application is so simple, I don't see why it should).

uint32_t parent; /* the parent PID */
uint32_t child; /* the child PID */
uint32_t action; /* the command */

Action is one of the following

0x1, REGISTER

This requests that child specified should be terminated when the parent itself is no longer alive.

0x2, UNREGISTER

Notifies orphand that child has been properly reaped and should not be terminated once parent has terminated.

0x3, PING

This message simply checks for the responsiveness of orphand. If functioning properly, orphand should reply in a timely manner