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 fi 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<mailto:[email protected]> Sent: 1/21/2015 11:23 AM To: [email protected]<mailto:[email protected]> 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. -- Laurent
