[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


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.


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
 *   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

 *   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: