Bug#655467: ITP: perp -- A persistent process supervisor
Package: wnpp
Severity: wishlist
Owner: Sergiusz Pawlowicz <debian@pawlowicz.name>
* Package name : perp
Version : 2.05
Upstream Author : Wayne Marshall <wcm@b0llix.net>
* URL : http://b0llix.net/perp/
* License : BSD-2-clause-like
Programming Lang: C89/posix
Description : A persistent process supervisor
about
-----
The perp package provides a set of daemons and utilities to reliably
start, monitor, log, and control a collection of persistent processes.
A "persistent process" is any program intended to be long-running,
highly available, and purpose critical. Also known and often described
as a "service", a persistent process normally provides some essential,
on-demand system service. Programs that serve email, domain name
queries, and http requests are all examples of services that are
normally run as persistent processes.
These are the programs that you want to start at system boot, and to
continue running for as long as the system itself. These are the
programs you need running in uninterrupted service, day and night,
forever and ever.
perp helps make sure that they do.
benefits
--------
perp provides the following benefits:
* easy, portable, platform-neutral service installation
* fast, asynchronous service startup
* consistent, reliable service execution environment
* easy administration
* reliable and complete logging facilities
perp is similar in purpose to the venerable daemontools program last
released in 2001, but provides a modern update with many advantages:
* easy configuration: in place service activation and no symlinks!
* single process: context switching for multiple supervisors is
eliminated
* everthing administered in one place, /etc/perp
* service reset capability
* fully FHS compatible
* colorized(!) service lister, readable timestamps...
* no slashpackage, no slashcommand, no slashdoc...
Meanwhile, perp continues to share many of the positive attributes of
daemontools:
* small, portable, autoconf-less, standard C89/posix sources
* daemons never malloc()
* make(1) agnostic
* links with dietlibc for small executables
And the author is even friendly!
Reply to: