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) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
