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