DragonFly On-Line Manual Pages
AIRDAEMON(1) airframe AIRDAEMON(1)
NAME
airdaemon - Run a program as a daemon process, restarting it if it dies
SYNOPSIS
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]
DESCRIPTION
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.
OPTIONS
Daemon Options
--retry=RETRY_DELAY
Wait RETRY_DELAY seconds after the child process exits abnormally
until trying to restart the child process. See also --retry-max
--retry-max=RETRY_MAX_DELAY
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.
--pidfile=PID_FILE
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.
--airdaemon-pidfile=PID_FILE
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.
--no-daemon
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.
--log LOG_SPECIFIER
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.
--verbose
Equivalent to --loglevel debug.
--version
If present, print version and copyright information to standard
error and exit.
EXAMPLES
The following will ping www.cert.org every 15 seconds until ping
returns sucess:
airdaemon --retry 15 -- ping -c 1 www.cert.org
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 www.cert.org
BUGS
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 <netsa-help@cert.org>.
AUTHORS
Tony Cebzanov and Brian Trammell for the CERT Network Situational
Awareness Group, http://www.cert.org/netsa
SEE ALSO
filedaemon(1)
2.8.0 17-Dec-2015 AIRDAEMON(1)