From 0a39023fd7229371dd3e505208a1c0e073414ac2 Mon Sep 17 00:00:00 2001
From: Laurent Bercot Licensing
@@ -101,7 +101,7 @@ library.
Download
-
git clone git://git.skarnet.org/s6
Daemontools-like utilities
diff --git a/doc/notifywhenup.html b/doc/notifywhenup.html
index 6f9b06b..9a288ac 100644
--- a/doc/notifywhenup.html
+++ b/doc/notifywhenup.html
@@ -60,19 +60,16 @@ against the s6 library or use any s6-specific construct:
daemons can simply write a line to a file descriptor of their choice,
then close that file descriptor, when they're ready to serve. This is
a generic mechanism that some daemons already implement.
-The administrator can
-then run the daemon under s6-notifywhenup,
-which will properly catch the daemon's message and update a state file
-itself, then notify all the subscribers
-with a 'U' event, meaning that the service is now up.
- Note that there is still a small race condition remaining:
-if the daemon writes a line then instantly dies, and the supervisor
-picks up the death before the s6-notifywhenup
-program picks up the line, it is possible for the event sequence written
-to the fifodir to be wrong - 'd' before 'U'. This should be extremely
-rare, but unfortunately the race condition is unavoidable. The only
-way to be absolutely race-free is to have the daemon perform its
-readiness notification itself, which requires specific support.
+
+ s6 supports that mechanism natively: when the +service directory for the daemon contains +a valid notification-fd file, the daemon's supervisor, i.e. the +s6-supervise program, will properly catch +the daemon's message, update a state file (supervise/ready), then +then notify all the subscribers +with a 'U' event, meaning that the service is now up and ready.
diff --git a/doc/s6-notifywhenup.html b/doc/s6-notifywhenup.html index cdd487c..cdfa693 100644 --- a/doc/s6-notifywhenup.html +++ b/doc/s6-notifywhenup.html @@ -18,6 +18,27 @@
+Starting with s6-2.1.4.0, the s6-notifywhenup program has been deprecated,
+because there was still a case (albeit extremely rare) where a race
+condition would occur and readiness would be improperly advertised.
+Readiness notification for a service can now be achieved via a
+notification-fd file in the
+service directory, containing the
+number of the descriptor the service will write its readiness
+notification newline to. The notification will directly be picked by
+s6-supervise.
+
+ Quick upgrade recipe: for every service using s6-notifywhenup, +replace the s6-notifywhenup invocation in your run script with +fdmove 1 3, then perform echo 3 > notification-fd. +Done! +
+ +s6-notifywhenup launches a daemon while listening to a file descriptor, and sends a 'U' event to a fifodir when it diff --git a/doc/s6-supervise.html b/doc/s6-supervise.html index 0c40aa1..78db1fa 100644 --- a/doc/s6-supervise.html +++ b/doc/s6-supervise.html @@ -59,6 +59,47 @@ if ./run exits too quickly. sends a 'x' event to ./event before exiting 0. +
+ s6-supervise does not support options, because it is normally not run +manually via a command line; it is usually launched by its own +supervisor, s6-svscan. + However, the behaviour of an instance of s6-supervise can be tuned via +various configuration files in the service directory. These files, and +what they do, are listed on the +service directory documentation page. +
+ ++ If the service directory contains a valid +notification-fd file when the service is started, or restarted, +s6-supervise creates and listens to an additional pipe from the service +for readiness notification. When the +notification occurs, s6-supervise creates a ./supervise/ready +file containing the absolute time when readiness occurred, then sends +a 'U' event to ./event. The ./supervise/ready +file is deleted on service death. +
+ ++ If the service is logged, i.e. if the service directory has a +log subdirectory that is also a service directory, and the +s6-supervise process has been launched by +that is also s6-svscan, then by default +the service's stdout goes into the logging pipe. If you set +notification-fd to 1, the logging pipe will be overwritten +by the notification pipe, which is probably not what you want. Instead, +if your daemon writes a notification message to its stdout, you should +set notification-fd to (for instance) 3, and redirect outputs +in your run script. For instance, to redirect stderr to the logger and +stdout to a notification-fd set to 3, you would start your +daemon as fdmove -c 2 1 fdmove 1 3 prog... (in execline), or +exec 2>&1 1>&3 3<&- prog... (in shell). +
+diff --git a/doc/s6-svlisten.html b/doc/s6-svlisten.html index c107b8e..2316a2b 100644 --- a/doc/s6-svlisten.html +++ b/doc/s6-svlisten.html @@ -64,8 +64,9 @@ support in the service programs. See this page for details.