From 5a318ce649a7a5f754892518a4452a519b41dac8 Mon Sep 17 00:00:00 2001
From: Laurent Bercot
Date: Fri, 4 Dec 2020 07:25:12 +0000
Subject: Big signal/command semantics change to svscan/supervise; add
s6-svperms.
---
.gitignore | 1 +
NEWS | 11 +-
doc/index.html | 1 +
doc/overview.html | 24 +++
doc/s6-supervise.html | 28 ++--
doc/s6-svperms.html | 135 +++++++++++++++++
doc/s6-svscan.html | 149 +++++++++----------
doc/s6-svscanctl.html | 75 ++++------
doc/servicedir.html | 9 --
doc/upgrade.html | 16 +-
package/deps.mak | 5 +-
package/modes | 1 +
package/targets.mak | 1 +
src/libs6/ftrigw_fifodir_make.c | 6 +-
src/supervision/deps-exe/s6-supervise | 2 +-
src/supervision/deps-exe/s6-svperms | 1 +
src/supervision/s6-supervise.c | 108 ++++++--------
src/supervision/s6-svc.c | 3 +-
src/supervision/s6-svperms.c | 272 ++++++++++++++++++++++++++++++++++
src/supervision/s6-svscan.c | 2 +-
20 files changed, 620 insertions(+), 230 deletions(-)
create mode 100644 doc/s6-svperms.html
create mode 100644 src/supervision/deps-exe/s6-svperms
create mode 100644 src/supervision/s6-svperms.c
diff --git a/.gitignore b/.gitignore
index 98f7368..93a1802 100644
--- a/.gitignore
+++ b/.gitignore
@@ -23,6 +23,7 @@
/s6-svwait
/s6-svlisten1
/s6-svlisten
+/s6-svperms
/s6-notifyoncheck
/s6-svdt
/s6-svdt-clear
diff --git a/NEWS b/NEWS
index 52c3405..4998b5b 100644
--- a/NEWS
+++ b/NEWS
@@ -4,7 +4,16 @@ In 2.10.0.0
-----------
- Bugfixes.
- - Changes to s6-svscan and s6-svscanctl.
+ - Changes to s6-svscan and s6-svscanctl: the list of commands
+that can be sent to s6-svscan has been thoroughly cleaned up.
+s6-svscan now scans and prunes on SIGHUP.
+ - Changes to s6-supervise and s6-svc: -X not supported anymore,
+nosetsid not supported anymore. SIGHUP now properly closes
+stdin/stdout to allow the service to naturally exit on EOF;
+SIGQUIT semantics changed to immediately bail. SIGINT is now
+trapped and forwarded to the service's process group.
+ - New binary: s6-svperms, implementing a split permissions
+model. (By default, everything is the same as before.)
In 2.9.2.0
diff --git a/doc/index.html b/doc/index.html
index 9a01f14..ceb854e 100644
--- a/doc/index.html
+++ b/doc/index.html
@@ -161,6 +161,7 @@ a user interface to control those processes and monitor service states.
The s6-svc program
The s6-svok program
The s6-svstat program
+The s6-svperms program
The s6-svwait program
The s6-svlisten1 program
The s6-svlisten program
diff --git a/doc/overview.html b/doc/overview.html
index 1b4cb5d..9e41824 100644
--- a/doc/overview.html
+++ b/doc/overview.html
@@ -379,6 +379,30 @@ implemented for instance in the
s6-rc package.
+ Fine-grained control over services
+
+
+ s6 provides you with a few more tools to control and monitor your
+services. services. For instance:
+
+
+
+ - s6-svstat gives you access to
+the detailed state of a service
+ - s6-svperms allows you to configure
+what users can read that state, what users can send control
+commands to your service, and what users can be notified of
+service start/stop events
+ - s6-svdt
+allows you to see what caused the latest deaths of a supervised
+process
+
+
+
+ These tools make s6 the most powerful and flexible of the existing
+process supervision suites.
+
+
Additional utilities
diff --git a/doc/s6-supervise.html b/doc/s6-supervise.html
index 2926f83..94504e3 100644
--- a/doc/s6-supervise.html
+++ b/doc/s6-supervise.html
@@ -108,11 +108,15 @@ daemon as fdmove -c 2 1 fdmove 1 3 prog... (in execline), or
- SIGTERM: bring down the service and exit, as if a
s6-svc -xd command had been received
- - SIGHUP: exit as soon as the service stops, as if a
-s6-svc -x command had been received
- - SIGQUIT: close stdin, stdout and stderr and exit as soon as
-the service stops, as if a
-s6-svc -X command had been received
+ - SIGHUP: close its own stdin and stdout, and exit as soon as the
+service stops, as if a s6-svc -x command
+had been received
+ - SIGQUIT: exit immediately without touching the service in any
+way.
+ - SIGINT: send a SIGINT to the process group of the service, then
+exit immediately. (The point here is to correctly forward SIGINT
+in the case where s6-supervise is running in a terminal and the user
+sent ^C to interrupt it.)
@@ -183,17 +187,9 @@ better to have a collection of service directories
single scan directory, and just run
s6-svscan on that scan directory. s6-svscan will spawn
the necessary s6-supervise processes, and will also take care of logged services.
- s6-supervise is not supposed to have a controlling terminal: it's generally
-launched by a s6-svscan process that itself does not
-have a controlling terminal. If you run s6-supervise from an interactive shell, be
-warned that typing ^C in the controlling terminal (which sends a SIGINT to
-all processes in the foreground process group in the terminal) will terminate
-s6-supervise, but not the supervised processes - so, the daemon will keep running
-as an orphan. This is by design: supervised processes should be as resilient as
-possible, even when their supervisors die. However, if you want to launch
-s6-supervise from an interactive shell and need your service to die when you ^C it,
-you can obtain this behaviour by creating a ./nosetsid file in the
-service directory.
+ s6-supervise always spawns its child in a new session, as a session leader.
+The goal is to protect the supervision tree from misbehaved services that would
+send signals to their whole process group.
You can use s6-svc to send commands to the s6-supervise
process; mostly to change the service state and send signals to the monitored
process.
diff --git a/doc/s6-svperms.html b/doc/s6-svperms.html
new file mode 100644
index 0000000..5b5d485
--- /dev/null
+++ b/doc/s6-svperms.html
@@ -0,0 +1,135 @@
+
+
+
+
+
+ s6: the s6-svperms program
+
+
+
+
+
+
+
+s6
+Software
+skarnet.org
+
+
+ The s6-svperms program
+
+
+s6-svperms allows the user to see, or modify, for a given
+list of services: who can read their states, who can send them
+control commands, and who can subscribe to up/down events for those
+services.
+
+
+ Interface
+
+
+ s6-svperms [ -v ] [ -u | -g group | -G group | -o | -O group ] [ -e | -E group ] servicedirs...
+
+
+
+ Without options, or with only the -v option,
+s6-svperms prints 3 lines to stdout for every service directory
+listed in servicedirs. Every line contains the name
+of the service directory, then the following information:
+
+
+
+ - status: - indicates who is allowed to read status
+information on the service, with commands such as
+s6-svstat or
+s6-svdt. The values can be owner,
+for only the owner of the service; group: name, for
+the owner and members of group name; or public,
+for all users.
+ - control: - indicates who is allowed to send control
+commands to the service, with commands such as
+s6 -svc. The values can be owner,
+for only the owner of the service; or group: name,
+for the owner and members of group name.
+ - events: - indicates who is allowed to subscribed to
+events sent by s6-supervise for this
+service, with commands such as s6-svwait
+or s6-svlisten1. The values can be
+group: name, for the owner and members of group
+name, or public, for all users.
+
+
+
+ If something goes wrong while reading a part of the configuration of
+a service directory, s6-svperms does not print the corresponding
+line to stdout; instead, it prints a warning message to stderr.
+
+
+
+ When invoked with other options, s6-svperms modifies the
+permissions of the service directories listed in servicedirs... as
+specified by the options. The same permissions will be applied to all
+the services listed in servicedirs....
+
+
+ Options
+
+
+ - -v : re-read the permissions after writing them, and
+print them to stdout.
+
- -u : restrict the status: and control:
+permissions to owner: only the owner of a service directory will
+be able to read its state or control the service. This is the default when
+s6-supervise starts a service for the first
+time.
+ - -g group : allow members of group
+group to read the status of the service, but not to control it -
+control will be restricted to the owner.
+ - -G group : allow members of group
+group to read and control the service.
+ - -o : allow everyone to read the status of the service,
+but restrict control: to the owner.
+ - -O group : allow everyone to read the
+status, and allow members of group group to control the
+service.
+ - -e : allow everyone to subscribe to events.
+ - -E group : only allow members of group
+group to subscribe to events. This is the default when
+s6-supervise starts a service for the first
+time, with group being the primary group of the s6-supervise
+process (most likely root).
+
+
+
+ group is normally a group name that will be searched in the group
+database. But if it starts with a colon (:), the rest of group
+will be interpreted as a numerical gid, and the group database will not be read.
+
+
+ Exit codes
+
+
+ - 0: success
+ - 1: something went wrong when reading permissions in one of the service directories
+ - 100: wrong usage
+ - 111: system call failed
+
+
+ Notes
+
+
+ - The default (restrictive) permissions are safe.
+ - Unless operation of a service is restricted information, it is also
+safe to make status: more permissive.
+ - Opening control: to a group can be useful for instance in a
+shared administration situation when individual administrators are not given
+full root powers.
+ - Making events: public bears a small risk of a local DoS attack
+preventing more subscriptions to events, so it is not recommended for
+supervision trees where such subscriptions are critical to operations - such
+as a set of root services managed by
+s6-rc.
+
+
+
+
diff --git a/doc/s6-svscan.html b/doc/s6-svscan.html
index 3a93e00..5d92174 100644
--- a/doc/s6-svscan.html
+++ b/doc/s6-svscan.html
@@ -27,7 +27,7 @@ the root or a branch of a supervision tree.
Interface
- s6-svscan [ -S | -s ] [ -d notif ] [ -X consoleholder ] [ -c max ] [ -t rescan ] [ scandir ]
+ s6-svscan [ -d notif ] [ -X consoleholder ] [ -c max ] [ -t rescan ] [ scandir ]
@@ -37,9 +37,8 @@ its current directory as the scan directory.
scan directory.
- If the ./.s6-svscan control directory does not exist,
s6-svscan creates it. However, it is recommended to already have a .s6-svscan
-subdirectory in your scan directory, because s6-svscan may try and execute into the
-.s6-svscan/crash or .s6-svscan/finish files at some point - so those
-files should exist and be executable.
+subdirectory in your scan directory, because it is used to configure s6-svscan
+operation, see below.
- From this point on, s6-svscan never dies. It tries its best to keep
control of what's happening. In case of a major system call failure, which means
that the kernel or hardware is broken in some fashion, it executes into the
@@ -49,19 +48,14 @@ that the kernel or hardware is broken in some fashion, it executes into the
- s6-svscan then occasionally runs scans or reaps,
see below.
- s6-svscan runs until it is told to stop via
-s6-svscanctl, or a signal.
-Then it executes into the .s6-svscan/finish program. The program is
-given an argument that depends on the s6-svscanctl options that were used.
- - If that execution fails, s6-svscan falls back on a .s6-svscan/crash
-execution.
+s6-svscanctl, or an appropriate signal (see below).
+Then it executes into the .s6-svscan/finish program, if present; if
+not, it exits 0.
Options
- - -S : do not divert signals. This is the default for now;
-it may change in a future version of s6.
- - -s : divert signals - see below.
- -d notif : notify readiness on file descriptor
notif. When s6-svscan is ready to accept commands from
s6-svscanctl, it will write a newline to notif.
@@ -94,76 +88,82 @@ of 500 is safe and provides enough room for every reasonable system.
- -t rescan : perform a scan every rescan
milliseconds. If rescan is 0 (the default), automatic scans are never performed after
the first one and s6-svscan will only detect new services when told to via a
-s6-svscanctl -a command.
-It is strongly discouraged to set
-rescan to a positive value under 500.
+s6-svscanctl -a command. Use of this option is
+discouraged; it should only be given to emulate the behaviour of other supervision
+suites. (-t5000 for daemontools' svscan, -t14000 for runit's
+runsvdir.)
Signals
- s6-svscan always reacts to the following signals:
+ s6-svscan has special handling for the following signals:
- - SIGCHLD : triggers the reaper.
- - SIGALRM : triggers the scanner.
- - SIGABRT : acts as if a s6-svscanctl -b command had been received.
+ - SIGCHLD
+ - SIGALRM
+ - SIGABRT
+ - SIGHUP
+ - SIGINT
+ - SIGTERM
+ - SIGQUIT
+ - SIGUSR1
+ - SIGUSR2
+ - SIGPWR (on systems that support it)
+ - SIGWINCH (on systems that support it)
- By default, it also reacts to the following signals:
+ Signals that are not in the above list are not caught by s6-svscan and will
+have the system's default effect.
-
- - SIGTERM : acts as if a s6-svscanctl -t command had been received.
- - SIGHUP : acts as if a s6-svscanctl -h command had been received.
- - SIGQUIT : acts as if a s6-svscanctl -q command had been received.
- - SIGINT : acts as if a s6-svscanctl -6 command had been received.
-
-
- But if the -s option was given, then instead of those default actions,
-s6-svscan uses configurable handlers: it forks and executes a program every time
-it receives one of the following signals.
+ The behaviour for the first three signals in the list is always fixed:
- - SIGTERM : fork and execute .s6-svscan/SIGTERM
- - SIGHUP : fork and execute .s6-svscan/SIGHUP
- - SIGQUIT : fork and execute .s6-svscan/SIGQUIT
- - SIGINT : fork and execute .s6-svscan/SIGINT
- - SIGUSR1 : fork and execute .s6-svscan/SIGUSR1
- - SIGUSR2 : fork and execute .s6-svscan/SIGUSR2
- - SIGPWR (on systems that define it) : fork and execute .s6-svscan/SIGPWR
- - SIGWINCH (on systems that define it) : fork and execute .s6-svscan/SIGWINCH
+ - SIGCHLD : trigger the reaper.
+ - SIGALRM : trigger the scanner.
+ - SIGABRT : immediately exec into .s6-svscan/finish (or exit 0 if that script does not exist), without waiting for any processes to die
- If an action cannot be taken (the relevant file doesn't exist, or isn't
-executable, or any kind of error happens), s6-svscan prints a warning
-message to its standard error but does nothing else with the signal.
-
-
-
- The -s mechanism is useful, for instance, when s6-svscan is running as
-process 1 and needs to trap signals such as SIGINT (sent on some systems by
-a Ctrl-Alt-Del press) in order to perform some specific work instead of
-executing into .s6-svscan/finish on the spot.
+ The behaviour for the rest of the list is configurable: on receipt of a
+SIGFOO,
+s6-svscan will try to run an executable .s6-svscan/SIGFOO file. For
+instance, a .s6-svscan/SIGTERM executable script will be run on receipt of
+a SIGTERM. If the file cannot be found, or cannot be executed for any reason, the
+default behaviour for the signal will be applied. Default behaviours are:
-
- s6-svscan will not exit its loop on its own when it receives a signal such as
-SIGINT and the -s option has been given. To make it exit its loop,
-invoke a s6-svscanctl command from the signal
-handling script. For instance, a .s6-svscan/SIGINT script could look
-like this:
-
-
- #!/command/execlineb -P
- foreground { shutdown-the-services }
- s6-svscanctl -i .
-
+
+ - SIGHUP : rescan and prune the supervision tree, i.e. make sure that new
+service directories visible from the scan directory have a
+s6-supervise process running on them, and instruct
+s6-supervise processes running on service directories
+that have become invisible from the scan directory to stop their service and exit.
+This behaviour can also be achieved via the
+s6-svscanctl -an scandir command. This is the closest that s6-svscan
+can get to the traditional "reload your configuration" behaviour.
+ - SIGINT : same as SIGTERM below.
+ - SIGTERM : Instruct all the s6-supervise to
+stop their service and exit; wait for the whole supervision tree to die, without
+losing any logs; then exec into .s6-svscan/finish or exit 0. This behaviour
+can also be achieved via the s6-svscanctl -t scandir command.
+ - SIGQUIT : same as SIGTERM above, except that if a service is logged
+(i.e. there is a foo service and a foo/log service)
+then the logging service will also be killed, instead of being allowed to exit
+naturally after its producer has flushed its output and died. This can solve
+problems with badly written logging programs, but it can also cause loss of logs
+since the logger may die before the producer has finished flushing everything. The
+behaviour can also be achieved via the s6-svscanctl -q scandir command;
+you should only use this if SIGTERM/-t fails to properly tear down the
+supervision tree.
+ - Others: no effect if an appropriate executable file in .s6-svscan/
+cannot be run.
+
The reaper
@@ -189,9 +189,10 @@ one second later.
The scanner
- Every rescan milliseconds, or upon receipt of a SIGALRM or a
+ Upon receipt of a SIGALRM or a
s6-svscanctl -a command, s6-svscan runs a
-scanner routine.
+scanner routine. (It also runs it every rescan milliseconds
+if the -t option has been given.)
@@ -217,8 +218,8 @@ Every service the scanner finds is flagged as "active".
started in an earlier scan, but the current scan can't find the corresponding
directory, the service is then flagged as inactive. No command is sent
to stop inactive s6-supervise processes (unless the administrator
-uses s6-svscanctl -n), but inactive
-s6-supervise processes will not be restarted if they die.
+uses s6-svscanctl -n or a SIGHUP), but
+inactive s6-supervise processes will not be restarted if they die.
Notes
@@ -238,22 +239,10 @@ process commands at any time, even when the computer is in trouble.
memory. However, s6-svscan uses opendir(), and most opendir()
implementations internally use heap memory - so unfortunately, it's impossible
to guarantee that s6-svscan does not use heap memory at all.
- When run with the -t0 option, s6-svscan never polls,
-it only wakes up on notifications, just like s6-supervise. The s6 supervision
-tree can be used in energy-critical environments.
- The supervision tree (i.e. the tree of processes made of s6-svscan and
-all its scions) is not supposed to have a controlling terminal; s6-svscan
-generally is either process 1 or a child of process 1, not something that is
-launched from a terminal. If you run s6-svscan from an interactive shell, be
-warned that typing ^C in the controlling terminal (which sends a SIGINT to
-all processes in the foreground process group in the terminal) will terminate
-the supervision tree, but not the supervised processes - so, the supervised
-processes will keep running as orphans. This is by design: supervised
-processes should be as resilient as possible, even when their supervisors
-die. However, if you want to launch s6-svscan from an interactive shell and
-need your services to die with the supervision tree when you ^C it, you can
-obtain this behaviour by creating ./nosetsid files in every
-service directory.
+ Unless run with a nonzero -t option, which is only a legacy
+feature used to emulate other supervision suites such as daemontools or runit,
+s6-svscan never polls; it only wakes up on notifications.
+The s6 supervision tree can be used in energy-critical environments.