supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Avery Payne <avery.p.payne@gmail.com>
To: Steve Litt <slitt@troubleshooters.com>
Cc: dng@lists.dyne.org,
	"supervision@list.skarnet.org" <supervision@list.skarnet.org>
Subject: Re: Supervision scripts (was Re: OpenRC and Devuan)
Date: Fri, 6 May 2016 15:49:06 -0700	[thread overview]
Message-ID: <CABjZzt3L11UqcvW8qDqe8Ltj07TqTZU+9FDqp_s6NK_dOtkdZw@mail.gmail.com> (raw)
In-Reply-To: <20160504123929.7f71be13@mydesk.domain.cxm>


[-- Attachment #1.1: Type: text/plain, Size: 3056 bytes --]

Regarding the use of supervision-scripts as "glue" in distributions, yes,
the project was meant for that. Most - but not all of - the scripts are in
working order, as I use them at home on my personal server.  If you are
willing to take the time to remap the names (as needed), the scripts should
work out-of-the-box.  If you have questions, need help, or get stuck, write
to me and I'll do my best to give you answers.

Currently, these design problems remain:

* account name mappings that correspond to how the names are set up in the
installation,
* hard coded file pathing, which is inconsistent between distributions,
* handling of device names, which are inconsistent between kernels,
* handling of "instances", where one service will be "reused" over and over
(think multiple web servers of the same type on different ports),
* the "versioning problem", which I have (inadequately) described elsewhere
on the mailing list.  The current design addresses this.

My personal life has been very busy, and I needed a break, so there hasn't
been much movement.  Now that things are slowing, I can turn my attention
to it again this summer.  I have a plan to revitalize supervision-scripts
which addresses all (or most) of the listed design problems. The current
plan is:

* come up with clear definitions of the problems,
* a proposal, detailing solutions step by step, which will become a design
document,
* peer review of the document for inaccuracies and errors,
* close out the existing design and archive it,
* announce the old design as version 0.1, for historical interest,
* conversion of the existing design's data into new data structures, and
* finally, writing the code needed to generate the proper ./run files based
on the data provided.

The first step is mostly done.  The second one is just starting.


On Wed, May 4, 2016 at 9:39 AM, Steve Litt <slitt@troubleshooters.com>
wrote:

> On Tue, 3 May 2016 22:41:48 -1000
> Joel Roth <joelz@pobox.com> wrote:
>
> > We're not the first people to think about supporting
> > alternative init systems. There are collections of the
> > init scripts already available.
> >
> > https://bitbucket.org/avery_payne/supervision-scripts
> > https://github.com/tokiclover/supervision
>
> Those can serve as references and starting points, but I don't think
> either one is complete, and in Avery's case, that can mean you don't
> know whether a given daemon's run script and environment was complete
> or not. In tokiclover's case, that github page implies that the only run
> scripts he had were for the gettys, and that's pretty straightforward
> (and well known) anyway.
>
> As I remember, before he had to put it aside for awhile, Avery was
> working on new ways of testing whether needed daemons (like the
> network) were really functional. That would have been huge.
>
> Another source of daemon startup scripts his here:
>
> https://universe2.us/collector/epoch.conf
>
> SteveT
>
> Steve Litt
> April 2016 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
>

[-- Attachment #1.2: Type: text/html, Size: 4406 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

      parent reply	other threads:[~2016-05-06 22:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAC39vt1u0R6M3AFEMVs+7oE7y9t4wTxsC=4_RxGscF4WGy6CoA@mail.gmail.com>
     [not found] ` <20160504071507.GA9664@sprite>
     [not found]   ` <20160504084148.GB16716@sprite>
2016-05-04 16:39     ` Steve Litt
2016-05-04 18:18       ` Stephanie Daugherty
2016-05-06 22:49       ` Avery Payne [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABjZzt3L11UqcvW8qDqe8Ltj07TqTZU+9FDqp_s6NK_dOtkdZw@mail.gmail.com \
    --to=avery.p.payne@gmail.com \
    --cc=dng@lists.dyne.org \
    --cc=slitt@troubleshooters.com \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).