daemontools

The daemontools package provides a suite of utilities to start, run, log, and control server programs known as daemons, reliably and securely. (Quote from this fan page, official home page at D.J. Bernstein's web site)

It differs from typical unix setups in that it constantly monitors all its services and restarts them when necessary. It also comes with useful utilities to get all daemon-related features with any service. This makes it ideal for AxKit2, as its simplicity consequently means that it won't have those features built-in. Do one task, and do it well. Daemontools cares about running server processes the right way, and AxKit2 cares about serving interactive web applications.

In particular, running AxKit2 via daemontools instead of starting it manually gives you these features:

• automatically rotated log of STDERR
• constant monitoring, restarting it if necessary
• running AxKit2 under a specified user-/group-id
• setting resource limits to prevent DoS attacks or bugs taking down the system

Additionally, since daemontools play well with standard Unix utilities, you also get these features:

• limiting filesystem access via "chroot"
• distributing system resources individually via "nice"

Daemontools are configured via a special directory, /service. It contains subdirectories, one per service. Inside each subdirectory there must be an executable file "run", and there may be a subdirectory "log", itself containing a "run" executable.

Setting up (possibly multiple times) AxKit2 using daemontools would look like this:

/service/
   +--- site1/
   |      +--- env/
   |      |     +--- MEM
   |      |     \--- USER
   |      +--- log/
   |      |     \--- run
   |      +--- root/
   |      \--- run
   |
   +--- site2/
   .
   .
   .

Daemontools will create some additional files and directories for management purposes, but all we need is a "run" executable for AxKit2 itself, one for logging, the "env" subdirectory for configuration, and a symlink called "root" that points to the root directory of the server instance, probably the home directory of some user account.

Here is a viable script that starts up AxKit2 running as a certain user, with a decent memory limit:

#!/bin/sh
exec 2>&1 < /dev/null
[ -z "$USER" ] && exec envdir ./env "$0"
cd root
export HOME="$PWD"
exec softlimit -m $((MEM*1024*1024)) -c 0 -r $((MEM/4*1024*1024)) setuidgid "$USER" ./axkit

It is meant to be used with the first scheme presented in DirectoryLayout. It expects two configuration files, "env/USER" containing the user name and "env/MEM" containing a memory limit in megabytes (64 should be a decent size to catch a runaway process, but not interfere with regular usage). It also expects the following "log/run" script:

#!/bin/sh
[ -z "$USER" ] && exec envdir ../env "$0"
exec setuidgid "$USER" multilog t ../root/log/axkit2

This will log messages printed on STDERR to $HOME/log/axkit2/current, including a sub-second precision timestamp. Log files are rotated automatically, old log files will have the date of rotation in their name. To convert the high-precision timestamp into something human-readable, you can read the log with the command line:

tai64nlocal < log/axkit2/current | less

See the URLs given above for more information about daemontools, how to start/stop/kill services and similar things.

If you want to exploit other features like chrooting or changing the nice level, just modify the last command line in each of the scripts.