From 983061db31e02d62359dd8a0cb1e9f125950cfdb Mon Sep 17 00:00:00 2001
From: Laurent Bercot
Date: Thu, 13 Aug 2015 20:26:47 +0000
Subject: - add support for --livedir - doc fixes
---
doc/overview.html | 15 ++++++++-------
doc/s6-rc-compile.html | 17 ++++++++++++-----
doc/s6-rc-db.html | 11 +++++++----
doc/s6-rc-init.html | 9 ++++++---
doc/s6-rc.html | 10 ++++++----
doc/why.html | 19 +++++++++++--------
6 files changed, 50 insertions(+), 31 deletions(-)
(limited to 'doc')
diff --git a/doc/overview.html b/doc/overview.html
index fd544a7..2a90ee6 100644
--- a/doc/overview.html
+++ b/doc/overview.html
@@ -42,7 +42,7 @@ means bringing services up, or bringing services down.
Supervision suites manage long-lived processes, a.k.a
daemons, and sometimes call them services.
-With s6-rc, those things are different: a long-lived process is
+With s6-rc, things are a little different: a long-lived process is
also called a longrun and is a service, but a service
does not have to be a longrun. There is a second kind of service,
which is called a oneshot, and which represents a change
@@ -85,12 +85,13 @@ are both oneshots, both longruns, or a oneshot and a longrun.
- s6-rc also handles an additional kind of service: a bundle.
-A bundle is just a collection of oneshots or longruns, described
+ Oneshots and longruns are called atomic services.
+By opposition to atomic services, s6-rc also handles an
+additional kind of service that it calls a bundle.
+A bundle is just a collection of atomic services, described
under a single name. A bundle definition can even contain other
bundles, but ultimately a bundle will always represent a set of one
-or more oneshots or longruns. A oneshot or longrun is called an
-atomic service.
+or more atomic services.
Bundle names can be used anywhere with the s6-rc user
interface, and they will internally be converted to a set of
atomic services. An atomic service can depend on a bundle: it will
@@ -147,8 +148,8 @@ supervision tree is up and running. s6-rc will only work
if there is an active
s6-svscan
process monitoring a
-scan
-directory. On Linux, for instance, it is possible to achieve such a state
+scan
+directory. On Linux, for instance, it is possible to achieve such a state
by using an init created by the
s6-linux-init-maker
tool: when control reaches stage 2, s6-svscan is guaranteed to run,
diff --git a/doc/s6-rc-compile.html b/doc/s6-rc-compile.html
index 44327ba..6e539e4 100644
--- a/doc/s6-rc-compile.html
+++ b/doc/s6-rc-compile.html
@@ -159,14 +159,15 @@ character are ignored. The file defines the direct dependencies of
It is unnecessary to manually define complete sets of dependencies in the
dependency file, because
s6-rc will properly handle dependency chains.
-anyway. If A depends on B, no matter the underlying
+If A depends on B, no matter the underlying
implementation of B, and the current implementation of B
depends on C, then you should just put B in
A/dependencies; when starting the set,
s6-rc will start C first, then
B, then A. If the underlying implementation of B
changes and does not depend on C, then you will just have to
-modify the dependencies for B, not for A
+modify the dependencies for B, and the definition of A
+will still be correct.
@@ -182,13 +183,16 @@ complain and exit 1.
For oneshots
- - Two mandatory regular files named up and down, which
+
- Two regular files named up and down, which
must each contain a single Unix command line. The files will be interpreted by the
execlineb
lexer at compile time and the results will be stored into the
compiled database in an internal form. up will be run when
the service is started, and down will be executed when the service
-is stopped.
+is stopped. up is mandatory, but down is optional;
+if no down file is provided in the source definition directory,
+then s6-rc will consider that the down transition for this service
+does nothing and always succeeds.
@@ -255,7 +259,10 @@ about pipelines.
A mandatory regular file named run, as well as optional files
named finish, notification-fd and nosetsid. These
files will be copied, or recreated, in the generated
-service directory.
+service directory:
+they are meant to be used by the
+s6-supervise
+process that will manage the longrun service.
Optional directories named data and env. These will
be copied verbatim into the generated service directory.
An optional file named producer-for. If this file exists, then
diff --git a/doc/s6-rc-db.html b/doc/s6-rc-db.html
index a60658e..a9d8b9d 100644
--- a/doc/s6-rc-db.html
+++ b/doc/s6-rc-db.html
@@ -66,12 +66,15 @@ information to stdout, then exits 0.
compiled service database in compiled instead of
the current live one.
-l live : assume the live
-state is in live. Default is
-/run/s6-rc. This option is ignored if the
--c option has been given.
+state is in live. This option is ignored if the
+-c option has been given. Default is
+/run/s6-rc. The default can be changed at package
+compilation time, by giving the --livedir=live
+option to ./configure.
-u : for commands that use different data
depending on whether it's about bringing the service up or down,
-select the "up" data. This option is ignored when it is irrelevant.
+select the "up" data (this is the default). This option is
+ignored when it is irrelevant.
-d : for commands that use different data
depending on whether it's about bringing the service up or down,
select the "down" data. This option is ignored when it is irrelevant.
diff --git a/doc/s6-rc-init.html b/doc/s6-rc-init.html
index 39d11a7..3334525 100644
--- a/doc/s6-rc-init.html
+++ b/doc/s6-rc-init.html
@@ -35,7 +35,7 @@ invocation of the
compiled, live and scandir must be
absolute paths.
s6-rc-init expects to find a compiled service database
-in compiled. It expects to be able to create a directory
+in compiled. It expects to be able to create a directory
at live. It also expects that an instance of
s6-svscan
is running on scandir.
@@ -48,11 +48,12 @@ subdirectory of live, adds down files to the live copies
and links them into scandir. It then triggers
s6-svscan,
which will pick up the new service directories and start
-http://skarnet.org/software/s6/s6-supervise.html">s6-supervise
+s6-supervise
processes on them - but the service themselves will not be started
right away, because of the down files.
s6-rc-init waits for all s6-supervise processes to be
operational, then exits 0.
+
Options
@@ -70,7 +71,9 @@ Default is /etc/s6-rc/compiled.
the live directory, which should not exist prior to running
s6-rc-init, but should be under a writable filesystem - likely a RAM
filesystem. Default is
-/run/s6-rc.
+/run/s6-rc. The default can be changed at compile time by
+giving the --livedir=live option to
+./configure.
Typical usage
diff --git a/doc/s6-rc.html b/doc/s6-rc.html
index 75dba9a..1000159 100644
--- a/doc/s6-rc.html
+++ b/doc/s6-rc.html
@@ -50,7 +50,8 @@ change.
- s6-rc expects to find a functional live state in
-live (by default /run/s6-rc). The live state is
+live (by default /run/s6-rc, unless changed when the package
+was compiled). The live state is
normally created at boot time by
s6-rc-init. If the live state is
invalid, s6-rc complains and exits 4.
@@ -88,7 +89,8 @@ The s6-rc command operates on the selection.
- -l live : look for the
live state in live. Default is
-/run/s6-rc.
+/run/s6-rc. The default can be changed at compile-time by
+giving the --livedir=live option to ./configure.
- -a : add the current set of active services to
the selection. This is useful for instance at
shutdown time: s6-rc -da change
@@ -327,11 +329,11 @@ stored in the /zork directory instead of /run/s6-rc.
myservicebundle, as well as everything that depends on them.
- s6-rc -pun0 myservicebundle
+ s6-rc -pun0 change myservicebundle
Prints what s6-rc would do to bring the state to exactly
the contents of myservicebundle as well as its recursive
-dependencies, and pruning all the rest. Do not wait any extra time
+dependencies, and pruning all the rest. Does not wait any extra time
between simulated transitions.
diff --git a/doc/why.html b/doc/why.html
index f544e08..d392ab5 100644
--- a/doc/why.html
+++ b/doc/why.html
@@ -89,9 +89,9 @@ initialization scripts) and longruns (daemons), are needed.
Unix distributions usually come with their own init systems and
service managers; all of those have flaws one way or another. No
widely spread init system gets things right, which is the main
-reason for the recent "init wars" - there are strong, valid reasons
-to support such or such init system, but also strong, valid
-reason to dislike it.
+reason for the recent "init wars" - no matter what init system you
+talk about, there are strong, valid reasons to like it and support it,
+and there are also strong, valid reasons to dislike it.
@@ -173,7 +173,9 @@ because Apple doesn't see fit to provide a documentation page for
launchd) is very clear: it replaces init, rc, init.d/rc.d,
SystemStarter, inetd, crontd, atd and watchdogd. It does all of this
in process 1. And it uses XML for daemon configuration, so process 1
-has to link in a XML parsing library.
+has to link in a XML parsing library. Is this the sleek, elegant
+design that Apple is usually known for? Stick to selling iPhones,
+guys.
systemd,
the main protagonist (or antagonist) in the "init wars". It has the same
problems as launchd, up by an order of magnitude;
@@ -200,9 +202,9 @@ architects were obviously not Unix experts, which is a shame when
it's about creating a process 1 for Unix. This is apparent because:
They have been designed like application software, not
system software, which requires a fairly different set of
-skills, and careful attention to details - such as minimal software
-dependencies and shortness of code paths - that are not as important
-in application software.
+skills, and careful attention to details
+that are not as important in application software,
+such as minimal software dependencies and shortness of code paths.
@@ -226,7 +228,8 @@ readiness notification support, reproducible script execution, and
s6-rc is a service manager, i.e. the equivalent of
sysv-rc or OpenRC. It is not an init system.
You can run s6-rc with any init system of your choosing.
-Of course, s6-rc requires a s6 supervision tree to be running on
+Of course, s6-rc requires a
+s6 supervision tree to be running on
the system, since it delegates the management of longrun services
to that supervision tree, but it does not require that s6 be the
init system itself. s6-rc will work
--
cgit v1.3.1