Previous searches suggest using Ubic::Service::Plack but I fear our admins would object, as they already have init for running/stopping and zabbix for monitoring. I believe there are other people in the Perl community who have their reasons to stick to sys v init.

Now, there's Daemon::Control so I only have to reinvent a wheel of minimal diameter. Looks like there's some prior art, but I'd like to generalize a bit.

In my ideal world with unicorns and pegasi, the workflow should look like:

• Edit file /etc/plack/config.yml (first time only);
• Copy my app's spec into /etc/plack/apps.d (install script should be able to do it, too);
• Say service plack start and that's it.

The main config should contain: app files relocation (like /etc/plack/apps.d), sane defaults for apps, and probably more. Upon loading the config it should be checked for sanity, consistency, port/name/pidfile intersections, etc.

An app config may contain:

• app (path, required) - path to the PSGI application in question
• port (number, required) - desired port
• name (string) - symbolic name (both service plack restart $port and service plack restart $name should be OK)
• pid_file (printf-like) - pid file path format with %p for port and %n for symbolic name
• log_file (printf-like) - file where stdin and stdout are redirected
• server (command) - plackup, twiggy, etc.
• server_args (list) - additional args to be passed to the server
• env (hash) - hash of environment variables (e.g. PERL5LIB)
• dir (directory) - working directory of the script (by default should cd / or something)
• user (user|number) - user to run under
• group (group|number) - group to run under

Now some questions I'd like to ask before doing any serious development.

• How to name the executable, plack or psgi? Is Plack::InitScript a good name for the the underlying module (looks like PSGI namespace is reserved). I guess I should name everything the same way so that there's as little confusion as possible.
• File format - should I stick with YAML, or maybe there's some .ini variation, like git-config? Should it be possible to configure multiple services in one file?
• I'd also like to implement ping method to check that the app is really there and serves the content (by HEAD'ing some specific URI). Should it be a nonstandard ping command, a nonstandard --ping option, or just a separate script?
• Enabling/disabling - should I add a auto|enabled/noauto|disabled option to the application config, or use apache-like sites_available/sites_enabled approach? Should it be possible to temporary bring up an application that is normally off, or is it unneeded complexity?
• What else did I miss?