Bug#727708: The tech ctte isn't considering OpenRC at all
On 01/19/2014 08:15 PM, Ian Jackson wrote:
> How mature a system is and how well-developed in Debian are relevant
> factors
If we're making a competition of how long has an given init system been
in Debian, then for sure, OpenRC looses. However, on all the tests I
did, I see no major issue with OpenRC. Could you point to specific
issues that you've encountered? Otherwise, what do you have in mind
exactly, apart from "this is too new, so I don't trust it and therefore
refuse to even try it"?
> and it's not unreasonable to set a deadline, at which the
> state of the system in Debian will be the basis of our technical
> evaluation.
What's difficult for the TC, is that your decision also impacts the
future, not only the present. Only considering what we have right now
isn't unfortunately enough.
I do hope that you are also considering the possible outcomes of current
developments, and paths which has been taken by upstream. I believe it
has been the case already, for example, logind, udev, gnome, etc. and
their future support (using this or that init system) has been part of
this discussion.
It doesn't seem reasonable to just ignore future plans, and incoming
features which are currently in active development (see below about
s-vision patch, which I believe is a very good example illustrating what
I'm saying here).
On 01/19/2014 08:15 PM, Ian Jackson wrote:
> * The daemon does not double-fork; it runs in the foreground of
> of its initial process.
Something like start-stop-daemon then? :)
See also the command_background directive (in the man openrc-run).
On 01/19/2014 08:15 PM, Ian Jackson wrote:
> * The daemon's parent process (part of the init system) keeps
> track of it, so the init system knows whether the process
> is still running.
First, OpenRC isn't stateless like sysv-rc to begin with (try
"rc-status" to see what daemon is running). Status are kept in
/run/openrc/started using symlinks to /etc/init.d, and OpenRC uses
(optionally) cgroups to shutdown daemons, if that's what you ask.
Then, the answer to this question is even more definitively "yes", if
you use this patch:
https://github.com/qnikst/openrc/compare/s-vision
which uses monit for the process supervision. If you don't know monit,
well this probably means you haven't played much with servers. Monit has
been in Debian since 2002. It is a very mature tool which is great on
the server side. One of the very cool feature of Monit, is that it
includes email reports (so you know a daemon actually crashed), and
actual service functionality testing (like, is apache returning "hello
world!" when querying this URL, for example...), which none of the other
init system (to the best of my knowledge) implements yet. It is to me a
far more superior approach than just checking for a daemon to be just
"running" (but maybe crashed in a CPU-burn loop...).
I'm talking about a *working patch* here, not just "future plans". If I
didn't add it as a debian/patches add-on, this is because version 0.13
of OpenRC is supposed to be out soon, and it's my understanding that it
would be including it. So I do prefer to wait for the new upstream
release, but it's going to be there soon. Not taking this into account
isn't, IMO, reasonable.
On 01/19/2014 08:15 PM, Ian Jackson wrote:
> * The daemon's stderr goes somewhere reasonable.
Hum... By default, I honestly don't know what would be the behavior of a
daemon doing some output to stderr. However, I believe it'd be really
trivial to do in the command= statement of a runscript. Something like:
command="foo >/var/log/foo.log 2>&1"
or using the command_arg directive should be enough (I haven't tested,
but this seems reasonable).
Thomas Goirand (zigo)
Reply to: