On Thu, Oct 2, 2014 at 7:01 PM, Charlie Brady <
charlieb-supervision_at_budge.apana.org.au> wrote:
>
> On Thu, 2 Oct 2014, Avery Payne wrote:
>
> > On Thu, Oct 2, 2014 at 3:55 PM, Laurent Bercot <
> ska-supervision_at_skarnet.org>
> > wrote:
> > >
> > > Yeah, unfortunately that's not going to happen. You might get close
> for
> > > some
> > > services, maybe even a majority, but in the general case there's no
> direct
> > > mapping from a System V script to a supervision run script.
> >
> > Won't stop me from trying. Even if only 10% are "direct maps", that's
> > approximately 100+ scripts I don't need to write.
>
> What about 0%? No System V script execs the service so that it runs in the
> foreground. Startup would hang if it did.
>
The scripts in question are /etc/sv/(service)/run scripts, not the actual
init.d scripts. The plan is to use a set of templates, coupled with
environment variables, to handle all of that. The template has just the
bare necessities in it, with the last lines looking like
[ -f ./options ] && . ./options
exec chpst -P $DAEMONNAME $DAEMONOPTS
... where $DAEMONOPTS would have the necessary flags to cause the program
to run in the foreground. The environment variables are already
partially-set in /etc/default/(service) on Debian, and some of them do pass
the equivalent of $DAEMONOPTS in the init.d versions of the script. So I'm
not exactly re-inventing the wheel here. Worse case, if I need to, I can
place a /etc/sv/(service)/options file that does the same thing as
/etc/default/(service), and have the flags stored in there...I don't know
if Debian "allows" or "encourages" alteration of the /etc/default/(service)
stuff at the package level, but in case they don't, the options file would
be the backup plan to deal with that.
Of course, this only applies for simpler services that don't have "special
needs". I've already bumped into ejabberd wanting to "do its own thing".
Received on Fri Oct 03 2014 - 02:10:24 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:18 UTC