On 19/09/2015 11:23, Casper Ti. Vector wrote:
* In `s6:doc/servicedir.html':
Fixed, thanks.
* 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.
Grepping the current OpenRC git for "parallel" shows only a few instances of rc_parallel use; it seems to be used to defer waitpid() calls, which means OpenRC will be able to start/stop services without waiting for the exit code of previous invocations. This very much looks like an addition as an afterthought, not as an inherently parallel design. Unless I'm mistaken, there is no check for readiness; in the serial case, readiness is considered achieved when the invoked program exits. Using rc_parallel seems to defeat that design and possibly break service ordering: in other words, it is a hack that will only work if you're lucky, and goes contrary to the mechanics of OpenRC in the first place. Unfortunately, since most services get ready quickly enough and the Linux scheduler isn't retarded, problems rarely occur, as you have experienced; so it is not entirely obvious that rc_parallel is broken - but broken it is, and broken it will be unless the whole OpenRC engine is redesigned. You can't add parallel service start/stop as an afterthought. It has to be included in the design. OpenRC is a good serial rc system, but it's not a parallel rc system by any means.
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.
Indeed, it wouldn't be hard, but the question is, would it really be useful? Systems naturally do much more at boot than they do at shutdown. Booting is complex because there's a lot of configuration to perform; but for shutdown, you don't deconfigure everything in order - nobody cares since the system isn't going to live anyway. Even for partial service set changes, the cases where something should only happen when you bring a given set of services down, but nothing should happen when you bring them up, seem pretty limited to me. In general, when a given service needs to perform some teardown action, you do it in its own "down" file, not in a separate service. And in the few cases where it is actually useful, having an empty "up" file isn't hard. So, I don't mind the asymmetry because it's a natural one given the way a system works, and working around it is trivial. I only made the "down" script optional because it's true that a lot of oneshots won't have anything to do when being turned off; but the opposite is exceptional. Does it really bother you?
Finally, I acknowledge that code written by Laurent is excellent, but I also think some git commits by Laurent have really terrible summaries:
Guilty as charged. However, if you're talking about s6-rc, remember it has not been officially released yet, so the git log messages are purely intended for my own use. (Which is also true for the rest of my software, since I am the only developer, even if more people read the source; but it's even more true for s6-rc.) Also, most of these changes are 1. totally trivial, and 2. very unlikely to need a revert. A "git diff" would likely print just a few lines, and it's often really obvious that it's a fix for a very stupid bug. Especially in the development phase, when I'm just cleaning up the obvious mistakes - it's not about the evil sneaky bugs that need a long explanation. Same for the doc: if you're frustrated with a "doc update" commit message, a git diff will show exactly what's been added, and not much explanation is needed: I wrote a paragraph of documentation. Wheee. I promise I'll try to be more verbose and explicit in the commit logs for significant changes, and especially changes that add functionalities, i.e. things that may need a revert: it's important to know what commit broke stuff. For trivial modifications, I don't want to bother making nontrivial commit messages. Maybe I'm wrong about this.
Sorry if this mail does not seem quite humble...
As long as you're civil and relevant, that's really not a problem. We're all a big bunch of egos, no need to apologize for it. ;) -- Laurent
