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
Received on Sat Sep 19 2015 - 12:26:44 UTC