Since it has been public that Laurent schedules the release of s6-rc in
September 2015, I think it will be beneficial to try to rip the related
documentation of factual errors (I keep imagining how Rachel Carson and
her friends tried to eliminate flaws in "Silent Spring"). Here are my
own findings:
* In `s6:doc/servicedir.html':
In description of the `finish' file, there is "A finish script must do
its work and exit in less than 3 seconds", which (1) does not mention
the timeout can be modified in `timeout-finish' and (2) is out of sync
with the default value (5000ms, i.e. 5s) in the implementation in
`src/supervision/s6-supervise.c' and the description of
`timeout-finish' on the same HTML page.
* In `s6-rc:doc/why.html':
This "blurb" page describes OpenRC as starting (and shutting down,
though not explicitly saying that) services sequentially. This is
only partially true: in Gentoo, parallel startup and shutdown in
OpenRC can be enabled by setting `rc_parallel=YES' in `/etc/rc.conf'.
The comment in `rc.conf' says lock-up might still be encountered, but
I only experienced that problem three or four times several years ago,
among several thousand times of bootup hitherto.
By the way, I feel one behaviour of s6-rc can be slightly adjusted for a
good reason:
* In `s6-rc:doc/s6-rc-compile.html':
With current behaviour, oneshots mandates an `up' file, but not a
`down' file. At the first sight this asymmetry seemed really
unnecessary to me, and I remember recently reading one post on this
mail list asking about oneshots with only `down' functioning, so this
is not just imagination. Therefore, I propose to change the
requirements of oneshot from mandating `up' to mandating *at least one
between* `up' and `down'; I think this change should be technically
trivial and also backward-compatible.
Finally, I acknowledge that code written by Laurent is excellent, but
I also think some git commits by Laurent have really terrible summaries:
"s6-rc-update doc, bugfix", " and another one", "More work on
s6-rc-update", etc. Therefore, to ease future references, perhaps
Laurent can spend a little more time phrasing the summary when
committing more changes?
Sorry if this mail does not seem quite humble...
--
My current OpenPGP key:
4096R/0xE18262B5D9BF213A (expires: 2017.1.1)
D69C 1828 2BF2 755D C383 D7B2 E182 62B5 D9BF 213A
Received on Sat Sep 19 2015 - 09:23:04 UTC