airdaemon - Run a program as a daemon process, restarting it if it dies


    airdaemon   [--retry RETRY_DELAY] [--retry-max RETRY_MAX_DELAY]
                [--pidfile PID_FILE] [--airdaemon-pidfile PID_FILE] 
                [--log LOG_SPECIFIER] [--loglevel LOG_LEVEL]
                [--verbose] [--version] [--no-daemon]
                -- PROGRAM [PROGRAM_ARGS]


airdaemon invokes a child process and ensures that it is restarted if it encounters any errors. The delay between child exit and restart can be chosen, and can either be constant or exponentially increasing up to a specified maximum.

Use of two dashes (--) after all airdaemon command-line switches allows PROGRAM_ARGS to be interpreted by the PROGRAM rather than airdaemon itself. While they are not strictly required if you do not need to pass arguments to PROGRAM, they should be used for consistency.


Daemon Options


Wait RETRY_DELAY seconds after the child process exits abnormally until trying to restart the child process. See also --retry-max


This parameter, combined with the --retry parameter, facilitates truncated binary exponential backoff of the retry logic. The first retry attempt will be delayed by the value of the --retry parameter. If the child process exits abnormally within this time period, the delay is doubled. Once the child process survives longer than the value of the --retry parameter, the retry delay is reset to that value.

For example, assume --retry=30 and --retry-max=240. The first time the child process exits abnormally, airdaemon will wait 30 seconds before invoking the child process again. If it exits abnormally again within 30 seconds, airdaemon will wait 60 seconds and try again. If the process dies again within 30 seconds, the delay doubles again to 120. The process continues until the delay hits the maximum of 240. Once the child process survives for 30 seconds, the delay will be reset to the original retry delay of 30.


Write the process identifier of the child process to PID_FILE. Each time the child process is restarted, the process identifier in this file is updated. This option exists to facilitate the termination of the child process by shutdown scripts. Note that if the child process terminates normally during shutdown, airdaemon will terminate normally as well, so it is usually sufficient just to kill the pid in this file at shutdown.


Write the process identifier of the airdaemon process to PID_FILE. This option exists to facilitate the termination of the forked airdaemon process by shutdown scripts.


Do not actually daemonize. Mainly useful for testing/debugging.

Logging Options

These options are used to specify how log messages are routed. airdaemon can log to standard error, regular files, or the UNIX syslog facility.


Specifies destination for log messages. LOG_SPECIFIER can be a syslog(3) facility name, the special value stderr for standard error, or the absolute path to a file for file logging. Standard error logging is only available in --daemon mode if --foreground is present. The default log specifier is stderr if available, user otherwise.

--loglevel LOG_LEVEL

Specify minimum level for logged messages. In increasing levels of verbosity, the supported log levels are quiet, error, critical, warning, message, info, and debug. The default logging level is warning.


Equivalent to --loglevel debug.


If present, print version and copyright information to standard error and exit.


The following will ping every 15 seconds until ping returns sucess:

    airdaemon --retry 15 -- ping -c 1

The same as above, except the delay will double until reaching a maximum of 15 minutes:

    airdaemon --retry 15 --retry-max 900 -- ping -c 1


Known issues are listed in the README file in the Airframe source distribution. Note that airdaemon should be considered alpha-quality software; not every concievable input and aggregation is exhaustively tested at each release, and specific features may be completely untested. Please be mindful of this before deploying airdaemon in production environments. Bug reports and feature requests may be sent via email to <>.


Tony Cebzanov and Brian Trammell for the CERT Network Situational Awareness Group,