RE: Could s6-scscan ignore non-servicedir folders?

From: James Powell <>
Date: Wed, 21 Jan 2015 12:57:43 -0800

As an option to using strictly service run files, you could place one-shot services in Stage 2 prior to the service scan directory to run from traditional rc/init shell scripts with:

if [ -x /etc/s6-init/rc.d/rc.$SERVICE ]; then
/etc/s6-init/rc.d/rc.$SERVICE start

It's unsupervised but if you don't need a service supervised, it's a sure thing, plus it gives control over the service rather than directly calling it in Stage 2. You can even use a run file style script with an exec to launch it via s6-svscan and manage it, but manually rather than automatically.

Sent from my Windows Phone
From: Laurent Bercot<>
Sent: ‎1/‎21/‎2015 11:23 AM
Subject: Re: Could s6-scscan ignore non-servicedir folders?

On 21/01/2015 19:03, Steve Litt wrote:

> I do too. If you have a run-once thing that quickly returns, couldn't
> you just not exec the thing in the run script, and then have the last
> statement in your run script write a "down" file to the service? I'm
> assuming that s6 does down files the same way as daemontools.

  That's really using a supervision infrastructure for things it was
not made for. You don't want to spawn a s6-supervise process for every
one-shot script you're running!
  There have been attempts to use a process supervisor as a service
management framework before - you can check on the gmane archives.
It can be made to work, but it's always kludgy, brittle and
unsatisfying - at this rate, you're better off staying with sysvrc or
whatever your favorite system manager is.

  No, the right way to proceed is a real system manager that handles
one-shot programs too, and starts/stops daemons by feeding them to
the supervision tree, as nosh does. We don't have it yet - at least
not in pure C and working with s6/runit/daemontools - but it's on my
TODO-list, and in the meantime Avery is working on dependency scripts,
check with him.

Received on Wed Jan 21 2015 - 20:57:43 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC