Bug#727708: The tech ctte isn't considering OpenRC at all

[Nikolaus Rath]

Ian Jackson  writes:
> Nikolaus Rath writes ("Bug#727708: The tech ctte isn't considering OpenRC at 
> all"):
>> Ian Jackson  writes:
>> > Thomas, does OpenRC provide a means for do non-forking daemon
>> > startup ?
>> [...]
>> 
>> Ian, quoting from your previous evaluation of upstart
>> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1499):
> ...
>> I don't see how this is consistent with what you say about
>> OpenRC. Either the lack of features isn't a problem if they can in
>> principle be implemented in the future (in that case, upstart and OpenRC
>> are both viable candidates), or hypothetical features do not matter (in
>> that case this should also hold for upstart).
>
> Firstly, non-forking daemon startup and supervision is less of a
> feature and more of a design decision.  I think that doing it from
> scratch in a system which doesn't have it at all involves a lot of
> design decisions and a fair amount of programming work.
>
> Secondly, the features I list as missing for upstart are not IMO
> anywhere near as important.

I see, thanks for the clarification. To me implementing non-forking
startup in OpenRC seems about the same amount of work as implementing
systemd-style socket activation in upstart. 

> If you think OpenRC will soon have non-forking daemon startup, then
> excellent.  Can you explain to me how it will work ?

I don't think OpenRC is a good candidate for the default init and I
don't know about any plans to implement non-forking startup, so I'd
rather not do that. My actual goal was to have you reconsider the weight
you put on not-yet-implemented-but-easy-to-do features in upstart :-).


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: The tech ctte isn't considering OpenRC at all

[Ian Jackson]

Thomas Goirand writes ("Bug#727708: The tech ctte isn't considering OpenRC at 
all"):
> 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? :)

Err, no, becase...

> See also the command_background directive (in the man openrc-run).

(http://manpages.debian.net/cgi-bin/man.cgi?query=openrc-run&apropos=0&sektion=0&manpath=Debian+experimental&format=html&locale=en
  => Sorry, no data found for `openrc-run'.
I dgit cloned the package from experimental and used `man -l'.
Perhaps manpages.debian.net isn't working or hasn't updated yet.)

> 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.

Having looked at the FM for openrc-run, no, this is not what I meant
by a non-forking daemon startup.

I meant that the long-running process's parent is some kind of
supervisor process which will respond to information about its child's
process lifecycle (using SIGCHLD, waitpid).  (And that the
long-running process inherits, and does not close, a sensible stderr.)

And I don't think cgroups is the right answer.

> Then, the answer to this question is even more definitively "yes", if
> you use this patch:
> https://github.com/qnikst/openrc/compare/s-vision

You're suggesting then to use monit.  Are you saying that all of the
daemons in Debian ought to be converted to run under monit and that
this should be the default mode of operation ?

I just read the monit(1) manpage and saw this:

 | Monit detaches from the console, puts itself in the background and
 | runs continuously, monitoring each specified service and then goes
 | to sleep for the given poll interval, wakes up and start monitoring
 | again in an endless cycle.

This is probably great for a server system monitoring setup.  But it's
not really how an init system has to work.  Also, monit has a lot of
functionality which has nothing to do with init system.

Also I saw this in the section on service entry keywords:

 | pidfile Specify the  process pidfile. Every
 | process must create a pidfile with its
 | current process id. This statement should only
 | be used in a process service entry.

Are you _sure_ monit doesn't expect daemons to fork ?  Why does it
need a pidfile ?

> 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).

Oh god, please no more of this kind of thing.  My inittabs are already
full of it and this is what I'm trying to get rid of.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: The tech ctte isn't considering OpenRC at all

[Ian Jackson]

Nikolaus Rath writes ("Bug#727708: The tech ctte isn't considering OpenRC at 
all"):
> Ian Jackson  writes:
> > Thomas, does OpenRC provide a means for do non-forking daemon
> > startup ?
> [...]
> 
> Ian, quoting from your previous evaluation of upstart
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1499):
...
> I don't see how this is consistent with what you say about
> OpenRC. Either the lack of features isn't a problem if they can in
> principle be implemented in the future (in that case, upstart and OpenRC
> are both viable candidates), or hypothetical features do not matter (in
> that case this should also hold for upstart).

Firstly, non-forking daemon startup and supervision is less of a
feature and more of a design decision.  I think that doing it from
scratch in a system which doesn't have it at all involves a lot of
design decisions and a fair amount of programming work.

Secondly, the features I list as missing for upstart are not IMO
anywhere near as important.

If you think OpenRC will soon have non-forking daemon startup, then
excellent.  Can you explain to me how it will work ?

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: The tech ctte isn't considering OpenRC at all

[Russ Allbery]

Thomas Goirand  writes:

> 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.

monit is a fine tool, but it's really orthogonal to the question of what
an init system should do.  It's essentially an event-based monitoring tool
that, as you say, can monitor various aspects of a service apart from just
whether it's running and trigger arbitrary actions on that basis.  It will
work with any init system; in fact, normally it's configured to run init
scripts.

I don't see it as a substitute for the init system tracking accurate state
and PID of its daemons.  The point of knowing the state of daemons isn't
only to be able to restart them when they die, although that's certainly
important and one gets that effectively for free once one has state
tracking.  It's to ensure that everything else the init system is managing
stays consistent and is in a known state for features such as
dependencies.  If service A depends on service B, and you try to start
service B, you want the init system to know that service A has crashed and
isn't currently running so that it can take the correct actions.  And, of
course, the init system needs to know the correct PID to send various
signals to for such things as stop and refresh actions.

Now, you could possibly use monit as the component that does that.  But it
just moves the problem to figuring out how to do proper non-forking
startup and startup notification to monit instead of the init system.

I didn't recall monit having direct support for that, and I just now
reviewed the documentation and still don't see that documented.  Does
monit now support something like the systemd startup notification protocol
or the upstart expect stop protocol?

> 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...).

Service functionality testing is a nice feature for what monit is trying
to do, but it's somewhat less helpful in the context of the init system.

When configured by the local sysadmin, deciding that Apache is running if
something is responding on port 80 is fine, since the sysadmin knows
that's the only thing they're running on port 80.  But the init system
needs to have more accurate tracking than that, for exactly the same
reason that Debian Policy says that init scripts should not stop random
other processes that happen to have the same executable name as the daemon
the init script is supposed to be managing.  (Something that a lot of our
init scripts currently probably don't handle correctly, since doing this
properly without starting processes in the foreground using the strategies
used by either upstart or systemd can be quite tricky, although
start-stop-daemon tries to provide proper tools.)

There's definitely a place for monit in an overall systems architecture,
along with a way for monit to tell the init system "hey, you might think
this thing is running, but based on the additional probes I've been
configured to try, I think it's actually hosed."  But it's not solving
quite the same problem.

> 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).

The problem with just redirecting output to a log file is that now that
log file is impossible to rotate safely, since you can't rename foo.log
and tell the daemon to re-open a new file by that name.  In other words,
this is a great way to run a production server out of disk space, as I
have done multiple times in the past by using a technique like this and
not thinking it through.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: The tech ctte isn't considering OpenRC at all

[Thomas Goirand]

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

Bug#727708: The tech ctte isn't considering OpenRC at all

[Nikolaus Rath]

Ian Jackson  writes:
> Thomas Goirand writes ("Bug#727708: The tech ctte isn't considering OpenRC at 
> all"):
>> But that OpenRC just hasn't been considered just because of rumors is
>> really unacceptable.
>
> The reason I haven't seriously considered OpenRC for the default is
> that it wasn't ready.
>
> Perhaps things have improved.  But I don't think it is necessarily the
> TC's job to go back and revisit OpenRC in these circumstances.  How
> mature a system is and how well-developed in Debian are relevant
> factors 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.
>
>
> On to specifics:
>
> Thomas, does OpenRC provide a means for do non-forking daemon
> startup ?
[...]

Ian, quoting from your previous evaluation of upstart
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1499):

,
| [...]
| upstart's minimalism is very appealing to me.
| 
| It does, however, have a number of missing features.  Those I have in
| mind are:
|   - ability to log daemon output to syslog
|   - multiple socket activation (systemd socket activation protocol)
|   - socket activation for IPv6 (and datagram sockets)
| 
| Of these Russ rightly points out that lack of IPv6 support is rather
| poor; it is arguably not suitable for release in jessie without this.
| 
| However, crucially, these are all simple matters of programming,
| without difficult design decisions.  They IMO don't reveal structural
| problems with upstart's approach to things.
| [...]
| I therefore conclude that the default init system for jessie should be
| upstart.
`

I don't see how this is consistent with what you say about
OpenRC. Either the lack of features isn't a problem if they can in
principle be implemented in the future (in that case, upstart and OpenRC
are both viable candidates), or hypothetical features do not matter (in
that case this should also hold for upstart).


I'm not saying that the existing OpenRC and upstart features are on par,
but outright rejecting OpenRC just because of missing features does not
seem fair to me when you at the same time consider the missing upstart
features as irrelevant because they can still be implemented.


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: The tech ctte isn't considering OpenRC at all

[Russ Allbery]

Michael Gilbert  writes:
> On Sun, Jan 19, 2014 at 6:52 AM, Russ Allbery wrote:

>> But it was way behind both systemd and upstart in terms of readiness in
>> Debian going into this discussion, and the amount of catching up that's
>> required here for it to displace upstart as my second choice just
>> doesn't seem feasible for me.

> Shouldn't this be seen as reason to slow things down?  Using a
> bureaucratic quality like "readiness" to make a technical decision seems
> like a contradiction.

At some point we have to make a decision.  We picked now.  This time is
not obviously worse than any other time.

There's always going to be one more system, or one more project, or one
more set of features, that might change the situation.  upstart developers
want to add socket activation.  systemd is going to be integrating with
kdbus.  The world is always going to change.  If we wait for everything to
stop changing, we'll never make a decision at all.

This argument has been ripping Debian apart for over a year, causing a lot
of serious unhappiness, very unpleasant threads in debian-devel,
frustrated maintainers, and maintainers who feel like they have to force
the issue in order to continue with their work.  The absence of a decision
is causing quite a lot of pain and is very demotivating to a lot of
developers.  I don't want to just let that continue until people give up
and find something else to do with their volunteer time.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: The tech ctte isn't considering OpenRC at all

[Michael Gilbert]

On Sun, Jan 19, 2014 at 6:52 AM, Russ Allbery wrote:
> But
> it was way behind both systemd and upstart in terms of readiness in Debian
> going into this discussion, and the amount of catching up that's required
> here for it to displace upstart as my second choice just doesn't seem
> feasible for me.

Shouldn't this be seen as reason to slow things down?  Using a
bureaucratic quality like "readiness" to make a technical decision
seems like a contradiction.

Anyway, why is there so much rush? jessie is going to default to
sysvinit no matter what.

Why not let the project evolve its own solution in the meantime?  The
TC could help that along more so by giving the project some guidelines
to best avoid obstructing each others init system work.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: The tech ctte isn't considering OpenRC at all

[Andreas Barth]

* Thomas Goirand (z...@debian.org) [140119 10:15]:
> Unfortunately, it seems it's going to be the way OpenRC will be
> evaluated: because some people *pretended* that OpenRC wouldn't fit the
> bill, it's just discarded without even having a look at how it works,
> its features, and its implementation.

That is - at least for me - not true: I look the same way at openrc as
the others. This however doesn't prevent me from arriving at certain
conclusions why I think one of the init systems is better than
another.



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: The tech ctte isn't considering OpenRC at all

[Dmitry Yu Okunev]

Hello.

On 01/19/2014 01:11 PM, Thomas Goirand wrote:
> On Fri, 17 Jan 2014 16:19:45 +0100, Josselin Mouette :
>> Oh, really?
>> Then can you explain why
>> https://bugs.gentoo.org/show_bug.cgi?id=391945
>> has not been marked as fixed?
> 
> It is the view of the upstream maintainers that the corner case where
> this happens doesn't happen in real life, so that bug can be ignored.

I want to add, that I've fixed the problem [1] on my local OpenRC copy.
Waiting for answer from Gentoo side about my patch.

[1] https://bugs.gentoo.org/show_bug.cgi?id=391945


I'm only a debian user but let me put two cents in again. Here's a look
from aside:

"systemd" and "upstart" gives _extra_ features, but sacrificing:
 - free community of init-system;
 - UNIX philosophy accordance.

There's a great lot of trash distributions like "ubuntu" or "fedora",
that are pursuing their own goals and forcing variety software. Debian
is the only universal binary distribution with big enough community that
can be used with conservative UNIX users, who believes in free community
and UNIX philosophy. IMO, software bundles (like "systemd") is a
proprietary way.

On the other hand OpenRC is really good solution supported by really
free and professional community. If you don't like something in it,
please, show corresponding bugreports, and OpenRC will likely fix that
all (if that will be reasonable). I personally saw only one minor
bugreport… and a lot of bugreports about "systemd".

OpenRC has extended cgroups support in 0.12 and it has parallel boot
support and all other and other reasonable features. And it's already in
experimental repositories of Debian (but I don't see any problem to test
OpenRC even if it's not in repositories).

The fact that the committee didn't even consider OpenRC despite the
community opinion is sad. I'm talking on forums with Debian users like
me, and a lot of them really want OpenRC. We even cannot understand why
OpenRC was been declined. Where's explanation of it's declination?

Don't you see, that the OpenRC is really the 3rd variant? And the only
one that is community driven. Or this's not an argument for Debian [1,
2] anymore?

[1] http://www.debian.org/intro/about
[2] http://www.debian.org/intro/free


P.S.: Sorry for my English.

-- 
Best regards, Dmitry,
head of UNIX-tech department NRNU MEPhI,
tel. 8 (495) 788-56-99, add. 8255



signature.asc
Description: OpenPGP digital signature

Bug#727708: The tech ctte isn't considering OpenRC at all

[Ian Jackson]

Thomas Goirand writes ("Bug#727708: The tech ctte isn't considering OpenRC at 
all"):
> I have to say that I'm really disappointed by the tech ctte attitude
> toward OpenRC in general.

I'm sorry about that, but:

The way I investigated both systems was by reading their documentation
and playing about with them (on the VMs Steve helpfully provided).

At the start of my investigations I asked where I could find the
reference documentation and no-one answered.  And, OpenRC wasn't in
sid.  So these things weren't possible.

> But that OpenRC just hasn't been considered just because of rumors is
> really unacceptable.

The reason I haven't seriously considered OpenRC for the default is
that it wasn't ready.

Perhaps things have improved.  But I don't think it is necessarily the
TC's job to go back and revisit OpenRC in these circumstances.  How
mature a system is and how well-developed in Debian are relevant
factors 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.


On to specifics:

Thomas, does OpenRC provide a means for do non-forking daemon
startup ?

By that I mean some arrangement whereby:

 * The daemon does not double-fork; it runs in the foreground of
   of its initial process.

 * 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.

 * The daemon's stderr goes somewhere reasonable.

If the answer to this question is "yes" then I will go and at least
read the documentation.  If it's "no" then I have to say that I think
(for me) OpenRC is failing to deal with the key underlying technical
problem we have with daemons in sysvinit right now.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: The tech ctte isn't considering OpenRC at all

[Russ Allbery]

Thomas Goirand  writes:
> On Fri, 17 Jan 2014 20:41:32 -0800, Don Armstrong wrote:

>> I should point out that I have not extensively examined openrc

> I have to say that I'm really disappointed by the tech ctte attitude
> toward OpenRC in general.

The reason why I'm not investing the time at present to set up a system
running OpenRC and writing init scripts for it is that I don't see what I
would learn from that to lead me to displace upstart as my second choice.

I realize that you're putting a lot of work into OpenRC packaging and you
believe in the technology, and I think it may well be a great choice for
non-Linux ports and, if we can manage the project-wide support, as an init
system for people who want something much simpler and more familiar.  But
it was way behind both systemd and upstart in terms of readiness in Debian
going into this discussion, and the amount of catching up that's required
here for it to displace upstart as my second choice just doesn't seem
feasible for me.

OpenRC has all of the same community momentum and logind integration
concerns as upstart does, has far less documentation than upstart (compare
openrc-run(8) to the Upstart Cookbook), is not as mature in Debian right
now, and doesn't have the advantage of Ubuntu's significant testing and
development of configurations in packages very similar to those in Debian.
It's even more dependent on shell scripting for common problems than
upstart is, which I consider a serious problem when trying to make simple
things easy and complex things comprehensible.  And it otherwise suffers
from many of the same drawbacks that upstart has relative to systemd.

The two advantages it has are that it's significantly more portable than
upstart, which I already decided wasn't a strong enough factor to be
conclusive in my preference for the default Linux init system as I spelled
out in my previous message, and it has a dependency-based system rather
than an event-based system.  I do think upstart's model is dubious, and
OpenRC's is closer to systemd, which I like better.  I think that may make
it a better choice for the non-Linux ports in the long run.  But I don't
think that's a strong enough advantage to overcome the other issues.

In short, OpenRC is a very nice extension of traditional shell-based init
scripts, but unless I'm missing some giant treasure trove of undocumented
features, I don't see anything that I'm going to learn by working with it
more that's going to change my mind about whether it should be the Linux
default.

You're understandably frustrated at people's misunderstandings, including
mine.  I thought it was less ambitious than it is, and it has features
that I thought were missing (although, to again point out that it's
playing catch-up here, several of those are ones you're actively working
on over the course of this discussion).  But note that the reason why
there are so many misunderstandings has much more to do with the fact that
there's *almost no documentation* than that we're being somehow unfair.
My first approach to both systemd and upstart, and I know Ian's as well,
was to read all the documentation that was available, and only then did I
start experimenting with the things that I didn't entirely understand from
the documentation.  I don't think that's an unreasonable approach, and I
think the lack of documentation is a significant concern by itself, apart
from the difficulties that causes for evaluation.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: The tech ctte isn't considering OpenRC at all

[Pacho Ramos]

El dom, 19-01-2014 a las 17:11 +0800, Thomas Goirand escribió:
> On Fri, 17 Jan 2014 20:41:32 -0800, Don Armstrong wrote:
> > I should point out that I have not extensively examined openrc
> 
> I have to say that I'm really disappointed by the tech ctte attitude
> toward OpenRC in general.
> 
> I pointed out to bdale (privately) as well that this was unacceptable.
> I've seen *many* quotes like this one:
> 
[...]

Maybe one option would be to use by default Systemd for Linux flavors
and openRC for the BSD ports :/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: The tech ctte isn't considering OpenRC at all

[Thomas Goirand]

On Fri, 17 Jan 2014 20:41:32 -0800, Don Armstrong wrote:
> I should point out that I have not extensively examined openrc

I have to say that I'm really disappointed by the tech ctte attitude
toward OpenRC in general.

I pointed out to bdale (privately) as well that this was unacceptable.
I've seen *many* quotes like this one:

Fri, 17 Jan 2014 16:46:43 +0100, Christoph Anton Mitterer wrote:
> I haven't really looked in depth at OpenRC or other solutions, since
> from the descriptions made by other people, I think it's not
> comparable to systemd/upstart.

Christoph, you don't *think*, you've just *heard of* from others (which
may be systemd or upstart supporters). Please learn to think by yourself!!!

Unfortunately, it seems it's going to be the way OpenRC will be
evaluated: because some people *pretended* that OpenRC wouldn't fit the
bill, it's just discarded without even having a look at how it works,
its features, and its implementation.

That OpenRC isn't the best, I can agree to *read* that, even if this
isn't my opinion. That it has less feature, I agree, but I don't think
the tech ctte choice should be driven by the number of features, but by
a set of requirements, and then choose the best implementation for them.

But that OpenRC just hasn't been considered just because of rumors is
really unacceptable.

It is my strong opinion that, because OpenRC is the only one which has
been ported to all Debian arch, and that because it has all the features
*that we need* (if you include the plugin patch for s-vision and monit,
which I'm currently evaluating and should be ready in days/weeks), and
because of the way it is implemented (eg: very light and easy to
understand/maintain), it is the best choice.

Don, please do your work and evaluate properly OpenRC. Otherwise, step
down and do not participate to the vote. Same goes for all tech ctte
members please!

On Fri, 17 Jan 2014 16:19:45 +0100, Josselin Mouette :
> That, I can definitely agree with. Although it is a shame that OpenRC
> chose a non-declarative format.

Joss, please stop posting stupid remarks about OpenRC. You don't know
it, and you don't seem to want to know it. That's the 2nd post in a week
that shows it, this is enough. OpenRC does have a declarative format, it
is just not mandatory and you can continue to use init scripts if you
like. Here's an example (from my blog, implementing the startup for
rsyslogd):
http://thomas.goirand.fr/blog/?p=147

Note that the sheebang should be replaced by /sbin/openrc-run since
runscript was renamed (because of clash with the program from minicom).
If you don't call this declarative, then you aren't being honest.

On Fri, 17 Jan 2014 16:19:45 +0100, Josselin Mouette :
> Oh, really?
> Then can you explain why
> https://bugs.gentoo.org/show_bug.cgi?id=391945
> has not been marked as fixed?

It is the view of the upstream maintainers that the corner case where
this happens doesn't happen in real life, so that bug can be ignored.
This has already been stated many times, and I'm sure you've heard about
it. I thought we were not having the debate this way. It seems you love
flame wars and can't help yourself. CAN YOU STOP NOW ???

Cheers,

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