- better error codes in s6-rc-update

 - doc fixes

3 files changed, 11 insertions, 8 deletions

diff --git a/doc/overview.html b/doc/overview.html
index 4209f42..12d5e4d 100644
--- a/doc/overview.html
+++ b/doc/overview.html
@@ -195,7 +195,7 @@ managed by s6-rc should be brought down in the proper order (via the
 brought down successfully, the final shutdown procedure can take place;
 for instance, if s6-svscan is running as process 1 with the
 <a href="http://skarnet.org/software/s6-linux-init/">s6-linux-init</a>
-defaults, <tt>s6-svscanctl -t /run/service</tt> will kill the
+defaults, <tt>s6-svscanctl -6 /run/service</tt> will kill the
 supervision tree and call <tt>/etc/rc.shutdown reboot</tt>, which should
 reboot the machine.
 </p>
diff --git a/doc/s6-rc-init.html b/doc/s6-rc-init.html
index e5ae884..67ed7de 100644
--- a/doc/s6-rc-init.html
+++ b/doc/s6-rc-init.html
@@ -109,6 +109,12 @@ similarly named, directory (<em>live</em><tt>:<em>suffix</em></tt>)
 and updates the live state by atomically changing the target of the
 <em>live</em> symlink - so <em>live</em> will not change names, whereas
 the real directory may.) </li>
+ <li> Similarly, it is recommended that administrators store their
+compiled service databases into some versioned directory, and that
+<em>compiled</em> be a symbolic link to the database currently in
+use. This will make it easier to create new compiled databases and
+switch them with <a href="s6-rc-update.html">s6-rc-update</a>
+without having to change the s6-rc-init invocation in boot scripts. </li>
 </ul>
 
 </body>
diff --git a/doc/s6-rc-update.html b/doc/s6-rc-update.html
index e9ab43c..f683952 100644
--- a/doc/s6-rc-update.html
+++ b/doc/s6-rc-update.html
@@ -59,12 +59,14 @@ live compiled service database. </li>
 
 <ul>
  <li> 0: success </li>
- <li> 1: failure to perform some state transitions </li>
- <li> 2: timed out </li>
+ <li> 1: failure to perform some state transitions, but the database was switched to <em>newdb</em> </li>
+ <li> 2: timed out, but the database was switched to <em>newdb</em> </li>
  <li> 3: unknown service name in the conversion file </li>
  <li> 4: invalid service database </li>
  <li> 5: wrong service type in the conversion file </li>
  <li> 6: duplicate service in the conversion file </li>
+ <li> 9: failure to perform some state transitions, and the database was not switched </li>
+ <li> 10: timed out, and the database was not switched </li>
  <li> 100: wrong usage </li>
  <li> 111: system call failed </li>
 </ul>
@@ -210,11 +212,6 @@ matter whether a service is renamed or not, changing its type will force a
 restart.
 </p>
 
-<tt>ps</tt> output as supervising the old name. This is purely cosmetic and
-will have no impact on the service; nevertheless, if you wish to avoid that,
-simply force a restart on every service you rename.
-</p>
-
 <h4> Restarting </h4>
 
 <p>