My research

perl plack server kill

perl plack server timeout

Starman

Signals

Supports HUP for graceful restarts, and TTIN/TTOU to dynamically increase or decrease the number of worker processes.

Superdaemon aware

Supports Server::Starter for hot deploy and graceful restarts.

Server::Starter

To gracefully restart the server program, send SIGHUP to the superdaemon. The superdaemon spawns a new server program, and if (and only if) it starts up successfully, sends SIGTERM to the old server program.

perl plack timer

Plack::Middleware::Debug::Timer - Debug panel to time the request

So you could create a middleware (like Debug::Timer), that based upon a time interval being exceeded, sends SIGHUP to $$, and hopefully the server you're using knows how to restart itself

Bingo, Plack::Middleware::SizeLimit - Terminate processes if they grow too large

After consulting with [irc://irc.perl.org/#plack], there is a flag for that

00:07    mst    : have your application set $env->{'psgix.harakiri'} e
+very N requests should do the trick
[download]

Its mentioned in http://search.cpan.org/~miyagawa/PSGI-1.09_3/PSGI/Extentions.pod

psgix.harakiri: A boolean which is true if the PSGI server supports harakiri mode, that kills a worker (typically a forked child process) after the current request is complete.

psgix.harakiri.commit: A boolean which is set to true by the PSGI application or middleware when it wants the server to kill the worker after the current request.

Hello again...   Thought I’d post a more-complete answer to my own question, just for the benefit of the next Gentle Reader Monk to stumble upon this thread.   My initial stumblings (and, as it were, the previous post-replies) are in fact somewhat incomplete and therefore misleading.   They identify the underlying self-destruct mechanism, yes, but they don’t pinpoint the right way to use it.

Modules such as e.g. Plack::Handler::FCGI have a manager option, which can either be the name of, or an instance of, a FCGI::ProcManager subclass.   (If none is specified, FCGI::ProcManager itself is used.)

One such manager-class just happens to be:   FCGI::ProcManager::MaxRequests, which among other things allows a max-requests value to be specified.   One convenient way to do this is by using the PM_MAX_REQUESTS environment variable (set e.g. by means of the SetEnv directive in Apache).   If the module looks for this variable and doesn’t find it (or if, by whatever means, the limit-value is omitted), the limit is assumed to be zero which of course means, “no limit exists.”   (A negative value is also taken to mean, “no limit exists.”)

Certain parameters of the Plack::Handler::FCGI constructor (namely, pid and nproc) are actually implemented by passing them to the Manager object if it is auto-instantiated, and must be omitted if instead you choose to provide a manager-object instance of your own.

If you peek underneath the covers of Plack::Handler::FCGI, you will see that it employs the “harakiri” capability.   Obviously, this is the approved way to do so, because it issues certain obviously-necessary calls to the proc-manager object along the way.

Now we know.   HTH™ ...

Perfect.

I kinda-sorta thought that such a facility must exist, and guessed that if it did exist it would more-or-less have to work like this.   I also knew that the original designer was Japanese.   I guess that part of my problem was that I didn’t know how to spell “harakiri...”   ;-)

The “SizeLimit” plugin is even nicer because it goes directly to the point.

As usual, I am once again Humbly Grateful to the Wisdom of the Esteemed Monks ...