Re: difference between bundles and dependencies in s6-rc

From: Colin Booth <>
Date: Fri, 26 May 2017 22:14:11 +0000

On Fri, May 26, 2017 at 03:58:15PM -0500, Brett Neumeier wrote:
> Hello Skaware!
> I'm in the process of setting up s6 and s6-rc as the init and service
> management systems for my linux system, and am curious: is there a
> significant functional difference between a bundle service, and a oneshot
> atomic service that does nothing but declares a bunch of other services as
> dependencies?
> If there is a functional difference -- what is it?
Hi Brett,

Getting a few things out of the way first, just so we're on the same

Dependencies are ordering constraints: A depends on B depends on means
that to bring up A, you first need to start B, which first requires C.

Bundles are groupings of services: Bundle 1, containing A, B, and C, can
be used as a shorthand to address all of those but internally there
aren't any ordering guarantees (unless A, B, and C also have

The functional difference then is this: telling a bundle to go up or go
down (especially important in the down case) will signal all contents of
that bundle to change state (in addition to anything that depends on
anything within the bundle or the bundle itself), whereas telling a
syncronization oneshot to go down will leave the stuff that it depends
on untouched.

In my own setups, I do both: I have essentially run-level bundles
(bndl-init, bndl-local, bndl-lan, bndl-all) that contain all the things
needed to make that level work. I then have a synchronization oneshot
that depends on those bundles and is a member of the next bundle up the
chain (so ok-init depends on init, and lives in local). That way, I can
go to a minimally functional state (init only) without having to mess
around with s6-rc shutting down udev or trying to remount half my disks.
Services that have specific requirements take a dependency on the atomic
in question, whereas things with wider-sweeping requirements like xdm or
a web server take a dependency on the synchronization point.

Received on Fri May 26 2017 - 22:14:11 UTC

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