Debian Bug report logs - #733452
init system daemon readiness protocol

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Paul Tagliamonte <paultag@debian.org>

To: submit@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: tech-ctte: Decide which init system to default to in Debian.

Date: Fri, 25 Oct 2013 12:16:04 -0400

[Message part 1 (text/plain, inline)]

Package: tech-ctte
Severity: normal
thanks


In response to the recent threads, I'd like to ask the tech-ctte to
please vote on and decide on the default init system for Debian.

There's been quite a lot of discussion and it's clear no consensus is
coming out of the discussion.

In addition, I find that developers care quite a bit (in both
directions), and dependencies / conflicts are only going to become more
common and serious for our users.


Thank you!
  Paul

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `-     http://people.debian.org/~paultag

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Thorsten Glaser <tg@mirbsd.de>

To: 727708@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: Re: tech-ctte: Decide which init system to default to in Debian.

Date: Fri, 25 Oct 2013 16:40:15 +0000 (UTC)

Paul Tagliamonte dixit:

>please vote on and decide on the default init system for Debian.

It’s not (just) about the _default_ but also on whether we will
force this default init system onto *all* our users, or whether
we commit to support more than one, and if so, how.

This is an *important* distinction / first step, and it absolutely
*must* be decided *before* the default is decided, because otherwise
the default system becomes just so much more important.

Why is it so hard to understand that this is (for me) about
freedom of choice?

I’d still say, let’s just GR about it. Prepare one now, then
have some time to cool down before the vote period.

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.		-- Coywolf Qi Hunt

Message #15 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Paul Tagliamonte <paultag@debian.org>

To: Thorsten Glaser <tg@mirbsd.de>

Cc: 727708@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: tech-ctte: Decide which init system to default to in Debian.

Date: Fri, 25 Oct 2013 12:48:03 -0400

[Message part 1 (text/plain, inline)]

On Fri, Oct 25, 2013 at 04:40:15PM +0000, Thorsten Glaser wrote:
> Paul Tagliamonte dixit:
> 
> >please vote on and decide on the default init system for Debian.
> 
> It’s not (just) about the _default_ but also on whether we will
> force this default init system onto *all* our users, or whether
> we commit to support more than one, and if so, how.

We've only ever supported one as a project; if you'd like to start
supporting more, please start a thread on that, and perhaps a release
goal.

> This is an *important* distinction / first step, and it absolutely
> *must* be decided *before* the default is decided, because otherwise
> the default system becomes just so much more important.

The default is the only thing we should support. Trying to support every
init system is insane, and again, this has implications on how daemons
are started, and small bugs for some radom daemon may start causing
subtle heisenbugs in unrelated apps.

> Why is it so hard to understand that this is (for me) about
> freedom of choice?

It may be, but it's not for the project. Let's let this bug be, and
have the tech cttie decide on *the* init system for Debian. If you want
to support more, again, please suggest it in another thread and/or bug.


Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `-     http://people.debian.org/~paultag

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Thorsten Glaser <tg@mirbsd.de>

Cc: 727708@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: tech-ctte: Decide which init system to default to in Debian.

Date: Fri, 25 Oct 2013 16:53:52 +0000 (UTC)

Paul Tagliamonte dixit:

>It may be, but it's not for the project. Let's let this bug be, and
>have the tech cttie decide on *the* init system for Debian. If you want

No, this must really really be decided first.

bye,
//mirabilos
-- 
<diogenese> Beware of ritual lest you forget the meaning behind it.
<igli> yeah but it means if you really care about something, don't
    ritualise it, or you will lose it. don't fetishise it, don't
    obsess. or you'll forget why you love it in the first place.

Message #25 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Paul Tagliamonte <paultag@debian.org>

To: Thorsten Glaser <tg@mirbsd.de>

Cc: debian-devel@lists.debian.org

Subject: Re: tech-ctte: Decide which init system to default to in Debian.

Date: Fri, 25 Oct 2013 12:57:28 -0400

[Message part 1 (text/plain, inline)]

On Fri, Oct 25, 2013 at 04:53:52PM +0000, Thorsten Glaser wrote:
> Paul Tagliamonte dixit:
> 
> >It may be, but it's not for the project. Let's let this bug be, and
> >have the tech cttie decide on *the* init system for Debian. If you want
> 
> No, this must really really be decided first.

Moving bug off CC. Please don't re-add it.

Feel free to start a new thread. Let that thread and bug be.

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `-     http://people.debian.org/~paultag

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Thorsten Glaser <tg@mirbsd.de>

To: 727708@bugs.debian.org

Cc: Ondřej Surý <ondrej@sury.org>

Subject: Re: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)

Date: Fri, 25 Oct 2013 18:22:44 +0000 (UTC)

Ondřej Surý dixit:

>then please submit your arguments directly there.

Sure.

>> Please stick to your side and make arguments for _your_ case, not

My “case” here is to ask CTTE to not make any decision and defer
to the Developers as whole, by means of a GR. As Guillem wrote:

| stop doing work due to this. Also even if a majority of the project would
| disagree with any such decision, subsequently overruling the tech-ctte by
| way of a GR requires more than a simple majority. You know, GRs do not
| eat babies or something.

I think that is, at this point, the only sensible way forward,
because the amount of people that would feel annoyed by a decision,
any decision, made by anyone, at this point in time is just too
large, and a GR is at least “by the people for the people”.

>> That doesn't take away Thorsten's will to make a GR, but I would like to
>> take the case to tech-ctte first.

I’m willing to wait with the GR until CTTE decided (or decided
to not decide), now that the process is started, but I’m not happy
(especially as we lose time considering time-based freeze).

bye,
//mirabilos
-- 
16:47⎜«mika:#grml» .oO(mira ist einfach gut....)      23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)    23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren	-- Michael Prokop über MirOS bsd4grml

Message #35 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Paul Tagliamonte <paultag@debian.org>

To: submit@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: Re: tech-ctte: Decide which init system to default to in Debian.

Date: Fri, 25 Oct 2013 14:43:44 -0400

[Message part 1 (text/plain, inline)]

And, since I've been informed that this was basically a contentless bug,
I'd like to frame the technical half of the question better:


Whereas:

 * the init system / pid 1 is a bit of software that multiple packages provide

 * the choice of init system also dictates which types of init scripts
   package maintainers write and maintain

 * the situation in which packages depend on a feature of systemd that's not
   dependent on pid 1 being systemd (such as dbus shutdown, or using logind)
   being run without systemd as pid1 is *not* something the systemd maintainers
   will support (fairly) is getting *more* common, and has been introduced into
   a major package (GNOME)

It is requested that the tech-ctte make a decision as to the init system
Debian shall use as the default, and make a judgement call on where the
efforts to resolve this situation shall go (patching *around* the lack
of systemd, or patching software to use systemd)

I believe this is within the ctte's jurisdiction, given 6.1 section 2.


Thanks for your consideration,
   Paul

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `-     http://people.debian.org/~paultag

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Thorsten Glaser <tg@mirbsd.de>

To: 727708@bugs.debian.org

Subject: Re: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)

Date: Fri, 25 Oct 2013 22:18:16 +0000 (UTC)

Okay,

and here’s the reasoning for “sticking to an antiquated” init system:

I fully believe that Debian should be as flexible as possible
when meeting users’ needs. There is already a big downstream
running on Upstart, and I believe that, given the assumption
that we need to decide on one/the init system, there is indeed
market for another big Debian downstream that runs on systemd
and offers GNOME after it has, by Neil’s suggestion (and, if
we decide to only support one init and it’s not systemd, that
*is* the logical outcome, *and* one I fully support), been
removed from Debian. This will cause “the market” to work and
make for some healthy competition, while accepting the goodies
from both downstreams to flow back into Debian if they’re good
enough (i.e. do not prevent sysvinit from working). This appears
to work pretty well with Ubuntu already, with early hostilities
(on both sides) having been overcome.

I believe that sysvinit allows for the most flexibility for
users and porters, and imposes the least on package maintainers
unwilling to write init scripts for more than one system. Both
newcomers support running packages from initscripts, whereas
it’s their way or the highway for the respective native scripts,
which may be added to Debian to be used by Debian users running
a nōn-default configuration (meaning with upstart of systemd as
init, which would presumably still be doable by users, but not
by packages, leading to the GNOME removal), and, of course, by
the aforementioned downstreams.

There needs to be said that sysvinit is the one closest to Unix
principles by not being as “integrative” (cf. modular), not
insisting on its own, proprietary binary logging format, and
other things. There may be a place for FLOS, but a Universal OS
is not it.

Additionally, sysvinit, at this point in time, is the only system
working universally across Debian thanks to the Hurd GSoC by Justus
Winter, whose Planet posts I read amazedly. I believe we should
solidify its status in Debian, as diversity is a good thing, and
the newcomers are not as portable (even if a GNU/kFreeBSD port of
upstart was begone). Downstreams may want to limit their set of
architectures for arbitrary reasons, so they would not have the
same constraints of being universal.

Finally, sysvinit is “the thing to expect” in the GNU/Linux
world, despite attempts from two big and a very small number
of smaller GNU/Linux vendors. Keep the principle of least
surprise and accept that sysvinit is the most universal one,
the one people coming from other GNU/Linux systems and even
some Unicēs will know, expect, or at least (if they’ve been
at Fedora before) know something about, and one which even
BSD people can accept and understand. It’s widespread, and
a good common denominator.

So I believe that, if we need to choose a default right now,
it must be sysvinit, and this must be a reliable outcome, i.e.
we commit to this and don’t arbitrarily change our mind later.
I believe that, should this question be forced first, GNOME
needs to be removed from Debian and welcomed as a downstream.

That being said, I would support upstart over systemd alone
for the fact that it doesn’t appear to do such “land grabs”,
is open for improvement (such as the kFreeBSD port) and not
as hostile as some of the people behind systemd/GNOME have
shown themselves to be, over and over again; I believe that
the fact of it being mainly driven by a company is not a big
problem (if needs be, fork it), especially as they have shown
themselves capable of doing large-scale projects in a mostly
technically sound manner, and be somewhat more consistent in
the implementation, as opposed to the perceived “a big change
every other week” of the other newcomer systemd.

bye,
//mirabilos
-- 
<ch> you introduced a merge commit        │<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
<ch> should have cloned into a clean repo      │  fault (core dumped)
<ch> if I rebase that now, it's really ugh     │<mika:#grml> wuahhhhhh

Message #45 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Lucas Nussbaum <leader@debian.org>

To: Paul Tagliamonte <paultag@debian.org>, 727708@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Sat, 26 Oct 2013 11:07:36 +0200

[Message part 1 (text/plain, inline)]

On 25/10/13 at 12:16 -0400, Paul Tagliamonte wrote:
> In response to the recent threads, I'd like to ask the tech-ctte to
> please vote on and decide on the default init system for Debian.

I agree. I don't think that many substantial new arguments are going to
be brought by waiting more on this topic. And it is clear that we have
reached a point where not having clear guidance is severely hurting the
project.

On 25/10/13 at 16:40 +0000, Thorsten Glaser wrote:
> I’d still say, let’s just GR about it. Prepare one now, then
> have some time to cool down before the vote period.

I think that it would be a failure of the Debian project if we had to have a GR
about such a technical decision. I think that we need to trust that the
Technical Committee will make the right decision. A GR about this will likely
result in splitting and hurting the project even more.

On 25/10/13 at 14:43 -0400, Paul Tagliamonte wrote:
> And, since I've been informed that this was basically a contentless bug,
> I'd like to frame the technical half of the question better:
> 
> 
> Whereas:
> 
>  * the init system / pid 1 is a bit of software that multiple packages provide
> 
>  * the choice of init system also dictates which types of init scripts
>    package maintainers write and maintain
> 
>  * the situation in which packages depend on a feature of systemd that's not
>    dependent on pid 1 being systemd (such as dbus shutdown, or using logind)
>    being run without systemd as pid1 is *not* something the systemd maintainers
>    will support (fairly) is getting *more* common, and has been introduced into
>    a major package (GNOME)
> 
> It is requested that the tech-ctte make a decision as to the init system
> Debian shall use as the default, and make a judgement call on where the
> efforts to resolve this situation shall go (patching *around* the lack
> of systemd, or patching software to use systemd)
> 
> I believe this is within the ctte's jurisdiction, given 6.1 section 2.

I think that there are two different questions:
1) Could you clarify which init system(s) must be supported by packages
   involved during system startup (daemons, etc.) and low-level services?
   
   [ the answer to that question would likely result into a update of
     the Debian Policy, section 9.3 and 9.11 ]

   [ Note that most daemons will likely still have to support sysvinit
     in jessie, in order to handle partial upgrades. ]

2) sysvinit is currently "Essential: yes", which causes it to be
   installed by default by the installer. Should sysvinit stay
   Essential? If not, should another init system be Essential?
   If not, how should this be addressed in the debian installer?

Lucas

[signature.asc (application/pgp-signature, inline)]

Message #50 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org

Cc: Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Sat, 26 Oct 2013 10:17:03 -0700

[Message part 1 (text/plain, inline)]

On Sat, Oct 26, 2013 at 11:07:36AM +0200, Lucas Nussbaum wrote:
> I think that there are two different questions:
> 1) Could you clarify which init system(s) must be supported by packages
>    involved during system startup (daemons, etc.) and low-level services?
    
>    [ the answer to that question would likely result into a update of
>      the Debian Policy, section 9.3 and 9.11 ]

>    [ Note that most daemons will likely still have to support sysvinit
>      in jessie, in order to handle partial upgrades. ]

> 2) sysvinit is currently "Essential: yes", which causes it to be
>    installed by default by the installer. Should sysvinit stay
>    Essential? If not, should another init system be Essential?
>    If not, how should this be addressed in the debian installer?

I don't think either of these are the right question.  Even if we change
the default init system for jessie, because we *must* support backwards
compatibility with sysvinit for upgrades, there is no justification for
requiring packages to do anything else for jessie and no policy change is
needed.

Likewise, the Essential: yes bit on the sysvinit package will be in effect
for a full release cycle regardless of what init system we choose, so it
needs to become a metapackage that depends on an ORed list of possible
implementations in order for us to make any change in jessie.

The real question before the TC is simply: what should the default init
system be for jessie?  The rest are technical details that can be
straightforwardly worked out once we have a decision on the direction.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #55 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Lucas Nussbaum <leader@debian.org>

Cc: 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Sat, 26 Oct 2013 10:46:38 -0700

Steve Langasek <vorlon@debian.org> writes:

> I don't think either of these are the right question.  Even if we change
> the default init system for jessie, because we *must* support backwards
> compatibility with sysvinit for upgrades, there is no justification for
> requiring packages to do anything else for jessie and no policy change
> is needed.

That isn't obvious to me.  We have, in the past, allowed upgrades to
require a preliminary upgrade of one or more packages.  The udev
transition comes to mind.  We *could* do the same thing here and require
an init upgrade as a pre-upgrade step when going from wheezy to jessie,
alongside a dependency on systemd or upstart (added by debhelper, for
example) for all packages providing startup configuration but not an init
script.  I'm not saying that's necessarily a good option, but it is an
option that we should discuss.

Also, we will eventually have to decide whether to drop the requirement
that packages provide sysvinit-compatible init scripts.  Even if we agree
on a requirement to do so for jessie, we could drop that requirement for
jessie+1 (and indeed will want to if we choose any init system other than
sysvinit or "all of the above," given that most of the benefits of either
upstart or systemd from a packaging perspective will only be seen when we
take that step).

We could always defer that decision until jessie+1, but that's the
decision with the most impact on kFreeBSD and Hurd, and if I were them,
I'd want to know whether that's the eventual project direction or not as
soon as possible so that I have as much time as possible to decide on my
next steps.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #60 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Russ Allbery <rra@debian.org>

Cc: Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Sat, 26 Oct 2013 11:20:21 -0700

[Message part 1 (text/plain, inline)]

On Sat, Oct 26, 2013 at 10:46:38AM -0700, Russ Allbery wrote:
> Steve Langasek <vorlon@debian.org> writes:

> > I don't think either of these are the right question.  Even if we change
> > the default init system for jessie, because we *must* support backwards
> > compatibility with sysvinit for upgrades, there is no justification for
> > requiring packages to do anything else for jessie and no policy change
> > is needed.

> That isn't obvious to me.  We have, in the past, allowed upgrades to
> require a preliminary upgrade of one or more packages.  The udev
> transition comes to mind.

udev transitions have always happened under duress.  We should do better
than this where we reasonably can.  (In the udev case, we had no choice but
to require a risky lockstep upgrade of the kernel and udev, because
maintaining udev compatibility with older kernels would have required an
excessive amount of new work.)

>  We *could* do the same thing here and require an init upgrade as a
> pre-upgrade step when going from wheezy to jessie, alongside a dependency
> on systemd or upstart (added by debhelper, for example) for all packages
> providing startup configuration but not an init script.  I'm not saying
> that's necessarily a good option, but it is an option that we should
> discuss.

Ok, point taken.  We *could* decide that something other than sysvinit was
now the new least common denominator for jessie, and using dependencies
ensure a smooth upgrade (i.e., this still wouldn't be the udev problem).  I
think that would be a surprisingly bold change for Debian to make in the
space of a single release cycle, when up to now we collectively have very
little experience running either systemd or upstart in production on Debian,
and we don't as yet have a resolution for compatibility with non-Linux
ports.

> Also, we will eventually have to decide whether to drop the requirement
> that packages provide sysvinit-compatible init scripts.  Even if we agree
> on a requirement to do so for jessie, we could drop that requirement for
> jessie+1 (and indeed will want to if we choose any init system other than
> sysvinit or "all of the above," given that most of the benefits of either
> upstart or systemd from a packaging perspective will only be seen when we
> take that step).

> We could always defer that decision until jessie+1, but that's the
> decision with the most impact on kFreeBSD and Hurd, and if I were them,
> I'd want to know whether that's the eventual project direction or not as
> soon as possible so that I have as much time as possible to decide on my
> next steps.

Right.  Whichever init system we pick, I do expect the next step to be to
drop the requirement to maintain sysvinit backwards-compatibility; my point
was that I don't expect this to be something we change in policy for this
cycle as part of the TC decision.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #65 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Sun, 27 Oct 2013 02:47:56 +0800

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi there!

I've been asked to write about OpenRC here. I'm a bit reluctant to do
it, but feel that it's my duty as I've been mentoring the OpenRC GSoC
project this summer.

Well, it's been a month the OpenRC package is waiting in the FTP NEW
queue (after a successful GSoC project), so it's a bit silly to tell
about something which isn't even in Debian yet... Though if anyone wants
to test it, it's in /git/collab-maint/openrc.git on Alioth.

Anyway, the main point of OpenRC, IMO, is that it can work on non-linux
platforms. But at this point, it is hard to make a case for it, since
the porting work (well, I should rather say the no-FTBFS work... as it
should be only a mater of configuring the build environment) hasn't been
done yet. :(

Note that OpenRC already works on some (non-Debian) BSD platforms, and
that it should be trivial to have it to build on kFreeBSD and Hurd,
though I didn't (and probably wont in the next few weeks/months, due to
professional duties and personal events) have time to work on this.
Though when this is done, OpenRC will be a drop-in replacement, with
normally very little trouble to take care of. I of course welcome anyone
to work on these ports.

With a bit more goodies than with sysv-rc (for example, cgroups support
for the platforms who supports it), OpenRC can be seen as an evolution
of it, with more features.

As for my own opinion on #727708, I'd like the tech committee to decide
we *must* continue to support something that works on kFreeBSD and Hurd
(either sysv-rc, or OpenRC when it's fully working on all arch) as a
requirement in the Debian policy, at least if we don't have an upstart
working port for Hurd / kFreeBSD (if this ever happens).

It is to be noted that it's Systemd upstream opinion as well that Debian
has no choice but to support something else than Systemd (sysv-rc,
OpenRC,...) scripts for platforms which wont ever be supported by
Systemd (I discussed about that with Lennart during Debconf).

Even if there's no such a decision from the tech-ctte, some ways of
starting daemons must be done for the non-linux Debian archs. And OpenRC
could be adopted for them (in the absence of Upstart / Systemd), to
simplify writing of these init scripts and bring more features. So,
whatever the tech-ctte decides, OpenRC, in my opinion, makes sense! :)

I also would like to wish good luck to the tech-ctte. Whatever you will
decide, I will support it. I wouldn't like to be in your seats, and I
hope everyone will also support your final decision.

Hoping that the work on OpenRC will be useful for Debian,
Cheers,

Thomas Goirand (zigo)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJSbA5ZAAoJENQWrRWsa0P+YYUP/37zqCtcornktT3xb7LKC4w7
ZdDig/g6cGW1JbL90q/6OPSN0CDUiVcF66HkP5RXk6jUG9CBm5OMmkz2+VX3THLR
Vhnyd/t5dQiyBLGgSO9YI4I9DizppasYjRpqsK7O3bI7cfmGgg8xyBk6CL3Kblvm
D7+jvRbBwdt+HqJccHsM4+n3mUgJFLOajVwU2E8Mp7TFY3bRwIyXWDPsE+7q0Jxi
1F1sS/bBxtaBOlj3tEAMRxLHH74bwKiT5VTo114ygQTu8ylsZ8hSCnNuDFSAm7mk
0TL28xaD1bA7VN2VwYd41J/KIWHel+0In5fG7FOIX1DGf543Fyei+CfpaINAHS+7
Yt8X2C/EFJr/4dERXTrxhxSN9T0B8fRvXwe1I6KEvcoyzIsEKjJO/yJxmr8NNrVA
w5Qp/jjLfrL82HlUIdvva4OonFCHGIVZkP+KFjTYMnKUJ9mlOnqCIF7m+cfH7ZkR
RFfodY3eWAiVY+Nq2SJ0EB9R+cslxXovotNvmMZQvagLIhlLC+qXMGTkV6VvXHbF
B0nVT6qCGmuDHQSUBCCeGy7nEKU1ObRcyfW3YJ0tiXmOTBuCBltHJpOiV4OwBcMK
7b20W8AtAyTbdtheksoUS4TSg25LOAQfeP0Gk0AVDV7nDDGLDVcCJ6L84JBjcu03
5wvRVoh1K0uf/pC/jWM9
=E/op
-----END PGP SIGNATURE-----

Message #70 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Arno Töll <arno@debian.org>

To: 727708@bugs.debian.org

Subject: RE: tech-ctte: Decide which init system to default to in Debian.

Date: Sun, 27 Oct 2013 13:06:03 +0100

[Message part 1 (text/plain, inline)]

Hi,

apart of the arguments raised by others, I'd like to point out three
more things:

- If we'd be inclined to switch the init system to something different
to sysvinit, let's start rather soon than later. Starting with today we
have one year until we expect to freeze which sounds like a lot, but
it's not if you take in mind that (up to) 1200 packages [1] need to be
adapted to this change, some in a non-trivial way. I guess any
alternative being discussed here is able to provide some fall-back
mechanism in case it's really needed, but if we rely on that, I don't
see a reason to switch in the first place. Thus, I'd appreciate if the
TC decides on that case rather soon than later since I'm one of these
persons who maintains several not-trivial init scripts.

- Please bear in mind that supporting more than one init script type is
not feasible or doable. Especially for non-trivial scripts [2][3]
maintaining an init script is a substantial piece of work, and I claim,
that we could spend our time in better ways than maintaining three
pieces of code (or, as for me, meta-language description files) which
all need to be tested, fixed and updated every once in a while. I guess,
I could deal with that burden once for Jessie, but please don't get us
into that as a long term solution.

- Whatever you decide, please do also turn your attention to the outside
world apart of Debian. This discussion was raised (well, this time),
because Gnome started to depend transitionally on systemd. Whether we
like it or not, but we're not the center of the universe. There are
distributions, and very important pieces of software outside the control
Debian and the TC that have (biased) points of view conflicting with
Debian's on this matter. Thus, I suspect that we are not going to
succeed with an isolated island solution, which does not care about the
ways other distributions move - especially since the init system choice
seems to be heavily tied to the choice of the desktop these days.
Whether it's systemd or upstart, both have major players standing behind
its respective technologies, each with substantial financial resources
to drive development of these platforms in a direction where Debian with
an isolated solution cannot compete with, due to its community driven
organizational structure.


[1] $ apt-file search /etc/init.d | wc -l
1194
[2]
http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/apache2.init;h=f5977abd302115e1517110fc2e00ca0cd2054afd;hb=HEAD
[3]
http://anonscm.debian.org/gitweb/?p=users/wouter/nbd.git;a=blob;f=debian/nbd-client.init.d;h=23994dd93b315533ee43bbb961b21aa40ff25c00;hb=HEAD

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D

[signature.asc (application/pgp-signature, attachment)]

Message #75 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: 727708@bugs.debian.org

Subject: Init systems: arguments for the CTTE

Date: Mon, 28 Oct 2013 10:36:48 +0100

Hi,

since this is the time to submit arguments before the CTTE can discuss
things internally and hopefully reach a decision, I’d like to say a few
words.

It won’t be a surprise if I say systemd should be the default init
systems for the Linux architectures for jessie and, unless another
solution arises, the only supported option for jessie+1.

I say this as a systems engineer, because systemd is great software. I’m
not going to list all systemd features, but there are many of them I
want to see on my production servers. In addition, the command-line
interface is awesome, and the unit file description is straightforward.

I say this as a package maintainer, too. Systemd is becoming a de facto
standard in Linux distributions (at least Fedora, SuSE and Arch), and is
getting excellent upstream support in many packages. So far, only Gentoo
uses OpenRC (and it doesn’t have most of the features I’d like to have),
and only Ubuntu uses Upstart. Therefore using OpenRC would mean
maintaining many patches on our own, and using Upstart would mean that
our upstream would become Ubuntu.

        As a side note, I think upstart’s CLA dismisses it as software
        of choice for our core system. 
        I know it’s not the only important piece of software in Debian
        with a CLA. I still stand on this point. I have experienced a
        real world CUPS nightmare because of Apple’s CLA, and I would be
        all for ditching CUPS as default too if we had a decent
        alternative.

Finally, I say this as one of the GNOME packages’ maintainers. GNOME in
jessie will need systemd as the init system to work with all its
features, just like it needs the network configuration to be handled by
NetworkManager. While it is (and can remain) possible, just like in the
NM case, to install it without systemd and lose functionality, I think
it is unreasonable to ask for a default GNOME installation without it.

Some people have argued this functionality can be reimplemented on top
of Upstart or OpenRC. These people should be ready to show the code and
to commit on maintaining it in the long term before it can be considered
as a possible alternative.

Finally, a word about kFreeBSD. I know systemd and upstart have not been
ported to kFreeBSD (and despite claims that upstart developers would
accept patches, so far they don’t exist). However, we are talking about
a major feature leap for Linux, and having kFreeBSD interfere in the
decision would be unfair to Linux users. 

My gut feeling is that, despite the original enthusiasm I shared,
kFreeBSD was branded a release architecture too soon, or at least for a
too broad set of packages. Most packages have never been tested on
non-linux, and a large portion of those does not work. A possible
approach would be to restrict these architectures to a defined set of
packages and maintain OpenRC or insserv scripts for these packages. In
all cases, this should be worked on after reaching a decision for the
Linux init system.

Thanks for reading,
-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-

Message #80 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Tollef Fog Heen <tfheen@debian.org>, Michael Biebl <biebl@debian.org>, Marco d'Itri <md@linux.it>, Thomas Goirand <zigo@debian.org>, Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org

Subject: Re: init system question before the technical committee

Date: Mon, 28 Oct 2013 12:04:58 +0000

Steve Langasek writes[1]:
> For my part, I think the suggestion that Russ and Lars made a while ago to
> maintain position statements in the Debian wiki is a good one, and I would
> encourage you to make use of this structure so that you can lay out your
> arguments in a way that doesn't require you to repeat yourselves endlessly
> in a mail thread.  The wiki is just waiting for someone to create the
> content:
> 
>   https://wiki.debian.org/Debate/initsystem/systemd

I would like very much to second this.  This discussion is going to
become unmanageable if we try to have it in the bug report and it will
be difficult to get any kind of overview.

I have been skimreading the messages from both sides here in the bug,
but I can't guarantee to give proper consideration to all of the
things which are said.

In summary: I, at least, intend to base my decision on how to vote
primarily on the information provided in the Debate wiki pages.


So I would appreciate it if you (and by "you" I mean each side of the
argument) would make sure that your page represents the best case you
can put forward.

In particular, I think for the systemd and OpenRC camps the first step
would be to set out who the maintainers are of the position
statement.  And then the points made in the emails need to be
transferred into the wiki and perhaps merged.

I'm expecting that the upstart camp will then want to add some
text to the section "Rebuttals" of their page.

For the avoidance of any doubt: only the listed position statement
maintainers should edit the page for a particular camp; with the
exception that if you agree with the thrust of the position statement
you may add something to "Comments" for the maintainer's
consideration.

Maintainers, please make sure you subscribe to updates the page for
your camp, so that you can spot any edits which don't confirm to this
rule.


Finally: we need this conversation to stay constructive and pleasant.
If anyone receives any rude, unprofessional or insulting messages (in
any medium) on this matter, please let one of the TC know.

Thanks,
Ian.

Message #85 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <wouter@master.debian.org>

To: Russ Allbery <rra@debian.org>, Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Mon, 28 Oct 2013 17:22:14 +0000

On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
> Right.  Whichever init system we pick, I do expect the next step to be to
> drop the requirement to maintain sysvinit backwards-compatibility;

While I'm not sure from your mail whether you meant to suggest otherwise, I do
think that whatever we decide for jessie, we should continue the requirement of
sysvinit compatibility for at least one release after we ship with some more
modern init system.

Also, since all alternative init implementations under consideration do
support sysv-style init scripts, I think that whatever init system we
(well, you, the TC) end up choosing, the requirement in policy should be
that a package should ship either some init configuration for the
default init system, or a sysv-style init script. In fact, I think we
should continue to encourage the latter, in cases where it does make
sense (e.g., when a given daemon doesn't have any init system specific
features that could be enabled), since that will help our non-Linux
ports without significantly impacting performance of the new init
system.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/

Message #90 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Alexander Wirt <formorer@debian.org>

To: Wouter Verhelst <wouter@master.debian.org>

Cc: Russ Allbery <rra@debian.org>, Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Mon, 28 Oct 2013 18:40:46 +0100

Wouter Verhelst schrieb am Monday, den 28. October 2013:

> On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
> > Right.  Whichever init system we pick, I do expect the next step to be to
> > drop the requirement to maintain sysvinit backwards-compatibility;
> 
> While I'm not sure from your mail whether you meant to suggest otherwise, I do
> think that whatever we decide for jessie, we should continue the requirement of
> sysvinit compatibility for at least one release after we ship with some more
> modern init system.
> 
> Also, since all alternative init implementations under consideration do
> support sysv-style init scripts, I think that whatever init system we
> (well, you, the TC) end up choosing, the requirement in policy should be
> that a package should ship either some init configuration for the
> default init system, or a sysv-style init script. In fact, I think we
> should continue to encourage the latter, in cases where it does make
> sense (e.g., when a given daemon doesn't have any init system specific
> features that could be enabled), since that will help our non-Linux
> ports without significantly impacting performance of the new init
> system.
It will also make backporting much easier.

Alex
 

Message #95 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Bdale Garbee <bdale@gag.com>

To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org, 727708@bugs.debian.org

Subject: Re: Bug#727708: Init systems: arguments for the CTTE

Date: Mon, 28 Oct 2013 11:47:52 -0600

[Message part 1 (text/plain, inline)]

Josselin Mouette <joss@debian.org> writes:

> While it is (and can remain) possible, just like in the
> NM case, to install it without systemd and lose functionality, I think
> it is unreasonable to ask for a default GNOME installation without it.

Thanks for making this clear.

Bdale

[Message part 2 (application/pgp-signature, inline)]

Message #100 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Michael Stapelberg <stapelberg@debian.org>

To: 727708@bugs.debian.org

Subject: FYI: upstream’s take

Date: Mon, 28 Oct 2013 19:34:38 +0100

Hi,

my apologies for not replying to any messages within the thread, but I
think my mail is orthogonal to the other messages.

Lennart Poettering wrote about the systemd upstream point of view on the
discussion we are currently having:
https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf

I’d like to specifically stress this part:
> And yeah, we, upstream, are of course open to answer any questions you
> might have.

So, please feel encouraged to explicitly ask upstream about any points
that you feel are important and/or unclear.

Also, it shouldn’t need saying, but let’s be sure: the same goes for
pkg-systemd-maintainers within Debian. If you have any questions, please
talk to us. You can reach us via
pkg-systemd-maintainers@lists.alioth.debian.org, and feel free to CC me
specifically.

-- 
Best regards,
Michael

Message #105 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 727708@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Mon, 28 Oct 2013 20:14:04 +0100

[Message part 1 (text/plain, inline)]

For those who haven't seen it, Lennart has posted some of his comments
about all this on G+:
https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #110 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 29 Oct 2013 00:45:53 +0000

[Message part 1 (text/plain, inline)]

Hi!

Please may I suggest another option for consideration:  a commitment to
support two chosen init systems.

On mainstream ports (Linux amd64, i386) where two init systems are
available, a package should be tested and made to work reasonably well
on both.  Any port would have at least one of these init systems.  This
offers users a choice to avoid a particular init system, try the new
features in another one, or perhaps stay with what they already have.

It would require work, but maybe this turns argument into something that
can be accomplished through team effort.  Supposing systemd and sysvinit
were chosen:
* systemd folks would aim to make best use of the existing sysvinit
scripts, and provide help to packages where improvement can be made;
* sysvinit users and porters can help ensure things keep working there.

I've begun a debate page here, more suggestions are welcome:
https://wiki.debian.org/debate/initsystem/multiple
or follow up on debian-devel@

Thanks!
Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

[signature.asc (application/pgp-signature, attachment)]

Message #115 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 29 Oct 2013 02:16:14 +0100

[Message part 1 (text/plain, inline)]

On Tue, 2013-10-29 at 00:45 +0000, Steven Chamberlain wrote:
> a commitment to
> support two chosen init systems.
The question is.... would supporting two be enough to give a
considerable benefit?

I guess the competition will be mostly between: systemd vs. upstart.
And not between sysvinit, anything else vs. systemd or upstart.

sysvinit is simply too old and lacks many modern features.
With anything-else, Debian would be more or less completely alone since
all world (except *buntu) seems to settle on systemd.
So from that POV, I'd even say upstart is already an island solution.
Look at most core daemons and systems/technologies (read about CUPS and
Wayland just a few days ago) - their upstreams seem to focus on systemd.


So when Debian really supports two init systems... what could that be?
Either

a) systemd AND upstart
I guess that would largely be a political benefit, since then the two
major fractions are happy.

b) (EITHER systemd OR upstart) AND sysvinit
That could have a real technical benefit, with respect to !Linux
flavours- since then we'd have systemd|upstart for Linux and sysvinit
for !Linux.
At least systemd does not support !Linux... and I guess it's the same
for upstart(??).

But then we'd have again the political problem of systemd vs. upstart,
since only one could win.


So *if* supporting multiple init-systems, and by supporting I mean, that
every package must support _at least_ those, then supporting 3(!) seems
to make more sense: sysvinit, systemd and upstart.

I generally hope, that the tech-ctte will not *forbid* the use of any
other init system, but just rule about a _minimum_ set of initsystems
(or one) that MUST be supported.


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #120 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Wouter Verhelst <wouter@master.debian.org>

Cc: Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Mon, 28 Oct 2013 18:21:27 -0700

Wouter Verhelst <wouter@master.debian.org> writes:

> Also, since all alternative init implementations under consideration do
> support sysv-style init scripts, I think that whatever init system we
> (well, you, the TC) end up choosing, the requirement in policy should be
> that a package should ship either some init configuration for the
> default init system, or a sysv-style init script. In fact, I think we
> should continue to encourage the latter, in cases where it does make
> sense (e.g., when a given daemon doesn't have any init system specific
> features that could be enabled), since that will help our non-Linux
> ports without significantly impacting performance of the new init
> system.

Well, I've said this before, but I think it's worth reiterating.  Either
upstart or systemd configurations are *radically better* than init scripts
on basically every axis.  They're more robust, more maintainable, easier
for the local administrator to fix and revise, better on package upgrades,
support new capabilities, etc.

I believe that much of the benefit for adopting a new init system is
dropping init scripts and using a much better configuration language.  If
we're not going to take advantage of that benefit, it calls into question
whether we should change init systems at all.

In other words, I don't think it would make any sense at all to
standardize on upstart or systemd and then ask people to continue to write
init scripts in the long run (transition issues aside).  Getting rid of
init scripts is not the whole point, but it's a huge part of it.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #125 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Peter Dolding <oiaohm@gmail.com>

To: 727708@bugs.debian.org

Subject: Re: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 29 Oct 2013 11:23:58 +1000

Anyone suggesting staying with sysvinit should be shot at down for
foolishness   If you wish to stay something sysvinit like you should
be backing OpenRC.

The basic issue with sysvinit is lack of process tracking.

This is the historic problem.

You start a service.
You stop a service.
Ok everything is fine.

You go to start service again.  Hello some random process is still
running so preventing the service starting because the service did not
stop properly.

Systemd and OpenRC both can address this using cgroups under Linux.
OpenRC also can use Jails under BSD line.

Upstart might be simpler to port but it does not address this base
problem at all.

The dbus issue is going to get major on all platforms.   This is
another http://www.freedesktop.org/wiki/Software/hal/ item.   Hal was
implemented in userspace and its functionality it has been replaced by
devicekit.  Same with the recent termination of userspace X11 drivers.

kdbus changes things major way.    Both upstart and openrc are well behind.

The big risk is after kdbus is in the Linux kernel items like kernel
power management move straight connected to it.   So there may be no
option bar use kdbus while running on the Linux kernel.

Debian has big trouble ahead.   No point putting head in sand.   The
Multi OS debian is means there is a lot of critical work that must
start straight now.   Like will kdbus be a feature we should expect
from all kernels debian supports?

Cgroups from Linux and  Solaris Containers from Solaris operate close
enough to make porting systemd possible.   The major road block to
systemd on freebsd kernel is nothing really like cgroups or Solaris
Containers.

Yes I know this would upset the freebsd guys no end but at this point
we do have to serously consider if the freebsd branch is even worth
keeping it is too alien to Linux.

Working with www.openindiana.org to bring on something that can be
systemd compatible as second kernel might be the correct way forward.
 Maybe then freebsd kernel developers would see the need to provide
Container class features in their OS kernel.

http://www.oracle.com/technetwork/articles/servers-storage-admin/intro-smf-basics-s11-1729181.html
Service Management Facility of Solaris and systemd of Linux have a lot
in common how they operate.   This is why porting systemd to Solaris
is not too bad.  cgroup functionality can be directly swapped with
Solaris Containers functionality.   Cgroups was not a magical new idea
that the Linux world dreamed up.   Someone had been look at Solaris
and liked what they saw.

This is really the choice do we keep on attempting to make
incompatible designed kernels interchange or do we move to kernels
with similar operating designs.

Yes we can still maintain the multi OS going forwards.   But we are to
the fork in the road.

Debian cannot support everything.    The project has to be willing to
spill blood at times.   I know killing kfreebsd branch completely is a
lot of blood shed.  But if that allows redirecting those resources to
a more compatible kernel so be it.

The big answer we need from freebsd kernel developers are they going
to implement functionality to match cgroup and solaris containers.
If not going forwards compatibility with them is going to become
harder and harder to maintain.

https://people.gnome.org/~alexl/glick2/  something people forget
container/cgroup class tech enable relocatable installation of
programs without the program seeing it.  Containers is something that
could be used in future to make multi-arch cleaner.   Like allowing
32bit and 64bit development files and applications to be installed
side by side without issues.  Like being able to install 32bit and
64bit ice-weasel at the same time.

The road block coming from freebsd is blocking systemd is also
blocking debian from using the same features to address other problems
as status normal.  Solaris kernel and Linux kernel could have
identical instructions given to developer to build packages due to the
existence of container tech in both.

Sorry everyone is hard choice time.
Do we go forwards having to work around the limited functionality of freebsd?
Do we nuke freebsd and move on to another kernel more compatible?
Do we pressure freebsd kernel developers to add containers?

Yes most people are missing the major road block to systemd on freebsd
is road blocking a solutions to stacks of other problems.   So really
this is more than a init system problem.   The fact systemd is not
portable to freebsd is showing missing features.   So far no one other
me has went out and looked at the other kernels to see if the bsd line
is a edge.   This case they are an outer edge.

Peter Dolding

Message #130 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: FYI: upstream’s take

Date: Mon, 28 Oct 2013 19:12:13 -0700

Michael Stapelberg <stapelberg@debian.org> writes:

> my apologies for not replying to any messages within the thread, but I
> think my mail is orthogonal to the other messages.

> Lennart Poettering wrote about the systemd upstream point of view on the
> discussion we are currently having:
> https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf

This is a valuable post.  Thank you for the pointer!  I would be
interested in seeing the two core technical arguments there (cgroup
handling and how D-Bus services are handled) addressed by the upstart
position paper, particularly if there are plans that Lennart isn't aware
of for how that functionality will be provided.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #135 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Lucas Nussbaum <lucas@debian.org>

To: 727708@bugs.debian.org

Cc: debian-devel@lists.debian.org, Helmut Grohne <helmut@subdivi.de>

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 29 Oct 2013 09:20:10 +0100

On 28/10/13 at 18:21 -0700, Russ Allbery wrote:
> Wouter Verhelst <wouter@master.debian.org> writes:
> 
> > Also, since all alternative init implementations under consideration do
> > support sysv-style init scripts, I think that whatever init system we
> > (well, you, the TC) end up choosing, the requirement in policy should be
> > that a package should ship either some init configuration for the
> > default init system, or a sysv-style init script. In fact, I think we
> > should continue to encourage the latter, in cases where it does make
> > sense (e.g., when a given daemon doesn't have any init system specific
> > features that could be enabled), since that will help our non-Linux
> > ports without significantly impacting performance of the new init
> > system.
> 
> Well, I've said this before, but I think it's worth reiterating.  Either
> upstart or systemd configurations are *radically better* than init scripts
> on basically every axis.  They're more robust, more maintainable, easier
> for the local administrator to fix and revise, better on package upgrades,
> support new capabilities, etc.
> 
> I believe that much of the benefit for adopting a new init system is
> dropping init scripts and using a much better configuration language.  If
> we're not going to take advantage of that benefit, it calls into question
> whether we should change init systems at all.

Note that there are two options that could be explored, to remove the
need to maintain init scripts:
- generating sysvinit scripts from systemd service files or upstart job
  files at build time (this was explored, for systemd service files,
  during a GSoC project in 2012, without much success)
- having a .service/job files runtime interpreter (that sounds quite
  promising)

Even if it cannot be used for all services, using such as interpreter
could maybe provide an easy support path for sysvinit on non-linux
platforms for a large number of "simple" services.

There's a subthread about that starting at
https://lists.debian.org/debian-devel/2013/05/msg01309.html
Helmut Grohne (Cced) did most of the work on analyzing those possibilities.

Lucas

Message #140 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Wouter Verhelst <wouter@master.debian.org>, 727708@bugs.debian.org

Cc: Russ Allbery <rra@debian.org>, Lucas Nussbaum <leader@debian.org>, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 29 Oct 2013 01:26:24 -0700

[Message part 1 (text/plain, inline)]

On Mon, Oct 28, 2013 at 05:22:14PM +0000, Wouter Verhelst wrote:
> On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
> > Right.  Whichever init system we pick, I do expect the next step to be to
> > drop the requirement to maintain sysvinit backwards-compatibility;

> While I'm not sure from your mail whether you meant to suggest otherwise,
> I do think that whatever we decide for jessie, we should continue the
> requirement of sysvinit compatibility for at least one release after we
> ship with some more modern init system.

The point was not about whether the init system would maintain
backwards-compatibility with sysvinit, which is straightforward to conserve
for some time, but whether individual packages providing services need to
maintain compatibility with sysvinit or if they can adopt the native service
definition format.  If we adopt a different init system as the default in
jessie, then certainly by jessie+1 at the latest, maintainers should feel
free to use the native format exclusively and not feel required to maintain
compatibility with sysvinit.

> Also, since all alternative init implementations under consideration do
> support sysv-style init scripts, I think that whatever init system we
> (well, you, the TC) end up choosing, the requirement in policy should be
> that a package should ship either some init configuration for the
> default init system, or a sysv-style init script. In fact, I think we
> should continue to encourage the latter, in cases where it does make
> sense (e.g., when a given daemon doesn't have any init system specific
> features that could be enabled), since that will help our non-Linux
> ports without significantly impacting performance of the new init
> system.

I see no reason that, if upstart were chosen as the default, porters could
not use it for our non-Linux ports as well.  This is a much better outcome
across our distribution as a whole than to require developers to continue
maintaining init scripts just for our non-Linux ports.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #145 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Helmut Grohne <helmut@subdivi.de>

To: Lucas Nussbaum <lucas@debian.org>

Cc: 727708@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 29 Oct 2013 10:22:54 +0100

TL;DR: Thoughts on using systemd .service files on non-Linux ports.

On Tue, Oct 29, 2013 at 09:20:10AM +0100, Lucas Nussbaum wrote:
> Note that there are two options that could be explored, to remove the
> need to maintain init scripts:
> - generating sysvinit scripts from systemd service files or upstart job
>   files at build time (this was explored, for systemd service files,
>   during a GSoC project in 2012, without much success)
> - having a .service/job files runtime interpreter (that sounds quite
>   promising)
> 
> Even if it cannot be used for all services, using such as interpreter
> could maybe provide an easy support path for sysvinit on non-linux
> platforms for a large number of "simple" services.
> 
> There's a subthread about that starting at
> https://lists.debian.org/debian-devel/2013/05/msg01309.html
> Helmut Grohne (Cced) did most of the work on analyzing those possibilities.

Thanks for inviting me to speak up here. Lucas asked me to summarize my
analysis of systemd/sysv integration earlier and I'll be giving this
summary (written for Lucas at that time) below.

For better separation of facts and opinion, let me point out my
motivation for working on this aspect. I believe that the declarative
service configuration of systemd and upstart is superior to init shell
scripts. Consequently, dropping the need for init shell scripts is the
only way to improve the situation (imo). Lacking time, I mostly
neglected upstart.

On 23/08/13 at 22:32 +0200, Helmut Grohne wrote:
> The existing converter (GSOC) can be found at
> https://github.com/akhilvij/systemd-to-sysvinit-converter.
> 
> My analysis of this project:
> https://lists.debian.org/debian-devel/2013/05/msg01309.html
> This includes a drafted idea on how to do runtime conversion.
> 
> Implementation details on runtime conversion: (last pragraph)
> https://lists.debian.org/debian-devel/2013/05/msg01337.html
> 
> Random details about service file conversion issues:
> https://lists.debian.org/debian-devel/2013/05/msg01334.html
> Important point over here: In .service files important dependency
> information has been elided by socket activation. Socket activation is
> official part of the dependency tree and any conversion utility that
> does not do socket activation will not produce correct boot ordering.
> 
> Statistical analysis of existing .service files in Debian.
> https://lists.debian.org/debian-devel/2013/07/msg00436.html
> 
> .service file parser written in C, could be used as a starting point.
> https://lists.debian.org/debian-devel/2013/07/msg00429.html
> 
> I presume that you are preparing arguments for a discussion with the
> CTTE about how to move forward with /sbin/init. The question of whether
> or how to support systemd .service files on non-Linux platforms will be
> asked over there.
> 
> The biggest issue I see here is the socket activation. It is mandatory
> for syslog, so no service will declare a dependency on syslog and just
> assume it to be present. On a technical level implementing socket
> activation on non-Linux platforms is possible. It would require a super
> server (similar to inetd) to be started early on and it would start
> .service files on request by other interpreted .service files when
> executed as init scripts. This amounts to reimplementing a fair part of
> systemd. The only alternative would be to annotate .service files with
> the missing dependency information, but which would likely be wrong most
> of the time.
> 
> I guess that an implementation that allows socket activation would be
> able to support around 50% of the currently existing .service files.
> 
> Bear in mind that systemd is a rapidly moving target. When I talked to
> Lennart about the idea of a portable .service file interpreter, he
> summarized future extensions to systemd that would raise the bar. The
> next issue will likely be the tight integration with dbus and later
> kdbus (the kernel implementation of dbus). By the time we would have an
> implementation featuring socket activation, we will likely need it to do
> dbus activation as well.

Having read the parts of the ctte bug, it feels odd to preclude the
option of supporting multiple init systems from discussion or
consideration. If Debian is to support only one init system and that one
init system is systemd, then given my above analysis it will be very
hard for non-Linux ports to catch up. I argue that in this case we
should consider dropping support for non-Linux ports. So if we really
are considering such an outcome, why not consider the outcome of
supporting multiple init systems (but maybe only one per architecture)?
This would become radically easier if gnome were to become Architecture:
linux-any.

In any case, feel free to ask me for answers or help with respect to
possible integration of systemd .service files in a non-Linux
environment.

I hope that this mail moves the discussion/decision forward.

Helmut

Message #150 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@ayous.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: FYI: upstream’s take

Date: Tue, 29 Oct 2013 11:51:37 +0100

* Russ Allbery (rra@debian.org) [131029 03:15]:
> Michael Stapelberg <stapelberg@debian.org> writes:
> 
> > my apologies for not replying to any messages within the thread, but I
> > think my mail is orthogonal to the other messages.
> 
> > Lennart Poettering wrote about the systemd upstream point of view on the
> > discussion we are currently having:
> > https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf
> 
> This is a valuable post.  Thank you for the pointer!  I would be
> interested in seeing the two core technical arguments there (cgroup
> handling and how D-Bus services are handled) addressed by the upstart
> position paper, particularly if there are plans that Lennart isn't aware
> of for how that functionality will be provided.

I'm wondering how much libcgroup matches (or not) the role of cgroup
handling - I use that in a different environment quite successfully,
but that might be just me and not the full answer for everybody.



Andi

Message #155 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@ayous.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: Init systems: arguments for the CTTE

Date: Tue, 29 Oct 2013 13:45:36 +0100

* Josselin Mouette (joss@debian.org) [131028 10:39]:
>         As a side note, I think upstart’s CLA dismisses it as software
>         of choice for our core system. 
>         I know it’s not the only important piece of software in Debian
>         with a CLA. I still stand on this point. I have experienced a
>         real world CUPS nightmare because of Apple’s CLA, and I would be
>         all for ditching CUPS as default too if we had a decent
>         alternative.

It is important for us that we can identify and fix bugs in our
packages, and that we could forward bug reports to upstream and have a
good working relationship with them (and allow them to pull our
patches).

However, lots of packages in Debian require copyright assignments to
bring patches upstream. This includes as central packages as gcc. One
could argue that the assignment policies between Ubuntu and FSF are
different enough that it matters. On the other hand, I don't see why
this is a blocker for us.

The upstart maintainers in Debian will work on bug reports and
proposed patches even without copyright assignment (as do the gcc
maintainers), and that is what is required for us. Of course I would
prefer if the copyright assignment policy would be changed, but that's
something else.

So, IMHO this topic is not a blocker for upstart (which doesn't on the
other hand automatically imply upstart is the right answer - this
depends on other questions and answers within this discussion).


Andi

Message #160 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 727708@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 29 Oct 2013 09:31:37 -0700

[Message part 1 (text/plain, inline)]

Hi Helmut,

On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote:
> Having read the parts of the ctte bug, it feels odd to preclude the
> option of supporting multiple init systems from discussion or
> consideration. If Debian is to support only one init system and that one
> init system is systemd, then given my above analysis it will be very
> hard for non-Linux ports to catch up. I argue that in this case we
> should consider dropping support for non-Linux ports. So if we really
> are considering such an outcome, why not consider the outcome of
> supporting multiple init systems (but maybe only one per architecture)?

While other members of the TC may wish to consider this option, I've ruled
it out myself because we would lose most of the benefits of switching away
from sysvinit and instead accrue significant maintenance costs to individual
developers who would then have to support both init systems in their
packages.  What makes switching init systems worth doing is being able to
*simplify* the interfaces between the init system and the services.
Continuing to support different init systems across different architectures
would add complexity instead.  That's a pretty bleak outcome.

There's nothing fundamental that prevents upstart from being ported to
non-Linux ports.  So certainly, if the TC decides for upstart, I see no
reason we would want to support sysvinit on ports instead of expecting the
porters to port upstart to their architecture.

> This would become radically easier if gnome were to become Architecture:
> linux-any.

GNOME may be the trigger for this being raised to the TC, but it's not the
core question that we need to address.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #165 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Paul Tagliamonte <paultag@debian.org>

Cc: 727708@bugs.debian.org

Subject: Re: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 29 Oct 2013 12:05:25 -0700

[Message part 1 (text/plain, inline)]

Hi Paul,

On Fri, Oct 25, 2013 at 02:43:44PM -0400, Paul Tagliamonte wrote:
> And, since I've been informed that this was basically a contentless bug,
> I'd like to frame the technical half of the question better:

Thanks for bringing this question to the Technical Committee.  It's been on
my todo list to raise this myself, with the intent of getting a TC decision
before the end of this year.  With only two months left in the year, it's
well past time that we start on this, so thanks for beating me to it.

In keeping with discussions I've had with other members of the TC regarding
what they feel would help with their decision making process, I've begun
preparing a wiki page outlining the position of the upstart maintainers on
why Debian should adopt upstart as the default init system for jessie.

   https://wiki.debian.org/Debate/initsystem/upstart

The page is not yet complete - in particular, I'm still fleshing out the
"why upstart and not systemd" section.  But there's enough there to give the
TC a starting point for discussion, I think.

> Whereas:

>  * the init system / pid 1 is a bit of software that multiple packages
>    provide

>  * the choice of init system also dictates which types of init scripts
>    package maintainers write and maintain

>  * the situation in which packages depend on a feature of systemd that's
>    not dependent on pid 1 being systemd (such as dbus shutdown, or using
>    logind) being run without systemd as pid1 is *not* something the
>    systemd maintainers will support (fairly) is getting *more* common, and
>    has been introduced into a major package (GNOME)

> It is requested that the tech-ctte make a decision as to the init system
> Debian shall use as the default, and make a judgement call on where the
> efforts to resolve this situation shall go (patching *around* the lack
> of systemd, or patching software to use systemd)

> I believe this is within the ctte's jurisdiction, given 6.1 section 2.

It seems to me that these are two separate questions, one dependent on the
other.  First we need to decide what jessie will use as the default init
system.  Once that's decided, if the decision is /not/ to use systemd, we
can look at making recommendations about how to approach upstream
incompatibilities; but while we should be aware that choosing a non-systemd
default does imply a certain amount of work, we shouldn't rathole on
deciding how to structure that work if we haven't even decided yet if that
work will be necessary.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #170 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Bruno Melo <brunosonic@gmail.com>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 29 Oct 2013 17:25:49 -0200

[Message part 1 (text/plain, inline)]

Hi guys, I'm just an user.
Well, can I make a suggestion?
We know systemd can't run on kFreeBSD and because of it Gnome can't run on
kFreeBSD too, but what about Cinnamon? Cinnamon is dependent on systemd?
1- If not, so Cinnamon + good apps can make kFreeBSD usable. So replacing
Gnome by Cinnamon on kFreeBSD (in CD-1, netinst, DVD-1 or whatever) is
feasible.
2- If yes, MATE can be another good idea (I already have build MATE on it
:D). MATE + good apps for example Pidgin, VLC, Brasero, and other).
3- In last case, if necessary kill kFreeBSD in favor to Illumos, the
OSDyson project still alive and can be adopted in Debian project. Or,
considering Gnome 3.10 is in OpenBSD ports, maybe a kOpenBSD is feasible.

I think FreeBSD is  not worried about the existence of systemd, and they
are using your init yet, so kFreeBSD can work around that too.
Sorry if I said some very absurd, I'm noob. Thanks.

[Message part 2 (text/html, inline)]

Message #175 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Paul Tagliamonte <paultag@debian.org>

To: Steve Langasek <vorlon@debian.org>

Cc: 727708@bugs.debian.org

Subject: Re: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 29 Oct 2013 16:44:09 -0400

[Message part 1 (text/plain, inline)]

On Tue, Oct 29, 2013 at 12:05:25PM -0700, Steve Langasek wrote:
> Hi Paul,

Good afternoon, Steve,

> Thanks for bringing this question to the Technical Committee.  It's been on
> my todo list to raise this myself, with the intent of getting a TC decision
> before the end of this year.  With only two months left in the year, it's
> well past time that we start on this, so thanks for beating me to it.

Happy to do it!

> In keeping with discussions I've had with other members of the TC regarding
> what they feel would help with their decision making process, I've begun
> preparing a wiki page outlining the position of the upstart maintainers on
> why Debian should adopt upstart as the default init system for jessie.
> 
>    https://wiki.debian.org/Debate/initsystem/upstart
> 
> The page is not yet complete - in particular, I'm still fleshing out the
> "why upstart and not systemd" section.  But there's enough there to give the
> TC a starting point for discussion, I think.

Great, that sounds like really productive stuff.

> It seems to me that these are two separate questions, one dependent on the
> other.  First we need to decide what jessie will use as the default init
> system.  Once that's decided, if the decision is /not/ to use systemd, we
> can look at making recommendations about how to approach upstream
> incompatibilities; but while we should be aware that choosing a non-systemd
> default does imply a certain amount of work, we shouldn't rathole on
> deciding how to structure that work if we haven't even decided yet if that
> work will be necessary.

Totally agree.

FWIW; I had a brief conversation with a core Gentoo developer about
their situation, and they also have a hard dep on systemd from GNOME,
even though their "default" is OpenRC.

As they're in the same situation, I can tell there's likely a lot of
cross-distro work that *can* be done in collaboration with another
(community driven) distribution if we decide to not default to systemd.

(such as maintaining replacements for components which require the hard
 systemd pid1 dep)


Thanks for taking this (very divisive) subject on,
   Paul

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `-     http://people.debian.org/~paultag

[signature.asc (application/pgp-signature, inline)]

Message #180 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Andreas Barth <aba@ayous.org>, 727708@bugs.debian.org

Subject: Re: Bug#727708: FYI: upstream’s take

Date: Tue, 29 Oct 2013 14:15:04 -0700

[Message part 1 (text/plain, inline)]

On Tue, Oct 29, 2013 at 11:51:37AM +0100, Andreas Barth wrote:
> * Russ Allbery (rra@debian.org) [131029 03:15]:
> > Michael Stapelberg <stapelberg@debian.org> writes:

> > > my apologies for not replying to any messages within the thread, but I
> > > think my mail is orthogonal to the other messages.

> > > Lennart Poettering wrote about the systemd upstream point of view on the
> > > discussion we are currently having:
> > > https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf

> > This is a valuable post.  Thank you for the pointer!  I would be
> > interested in seeing the two core technical arguments there (cgroup
> > handling and how D-Bus services are handled) addressed by the upstart
> > position paper, particularly if there are plans that Lennart isn't aware
> > of for how that functionality will be provided.

> I'm wondering how much libcgroup matches (or not) the role of cgroup
> handling - I use that in a different environment quite successfully,
> but that might be just me and not the full answer for everybody.

It does not.  The impending kernel transition is that there should be a
single process managing the cgroup heirarchy on behalf of userspace; the
existing libcgroup is a library that lets individual processes interface
with /sys/fs/cgroup, not an implementor of the userspace cgroup manager
service.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #185 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>

To: 727708@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 29 Oct 2013 23:59:26 +0100

[Message part 1 (text/plain, inline)]

On 28/10/13 20:14, Christoph Anton Mitterer wrote:
> For those who haven't seen it, Lennart has posted some of his comments
> about all this on G+:
> https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf

And here is the reply from Gentoo developer Patrick Lauer:

http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt

[signature.asc (application/pgp-signature, attachment)]

Message #190 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 727708@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 29 Oct 2013 16:16:04 -0700

Carlos Alberto Lopez Perez <clopez@igalia.com> writes:
> On 28/10/13 20:14, Christoph Anton Mitterer wrote:

>> For those who haven't seen it, Lennart has posted some of his comments
>> about all this on G+:
>> https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf

> And here is the reply from Gentoo developer Patrick Lauer:

> http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt

This, sadly, was not particularly useful or interesting.  As near as I can
tell, the core content was that he doesn't think cgroup management is
particularly difficult (fine, but I don't think that was the point; the
point, instead, was that it's important to have a single arbitrator, which
if true poses specific technical challenges) and he believes that the
components to systemd would be easy to implement as separate daemons if
they were properly documented.

I'm one of those people who thinks that nearly everything in Linux is
horribly underdocumented, so I'm not going to argue with that point, but
it's not a very useful statement from a practical viewpoint.  systemd
offers specific pieces of integrated functionality.  By and large, no one
seems to question that the operations enabled by that functionality are
useful (although there is some debate over how useful).  GNOME is not
depending on systemd out of some nefarious plot.  It's depending on
systemd because GNOME wants to use those pieces of functionality systemd
provides.

Therefore, I think it's important for arguments against using systemd to
somehow engage directly with the questions about functionality.  Either
there needs to be an argument that the functionality is not important and
can be done without (which raises questions about how one would build
GNOME in such an environment), or there needs to be some sort of plan for
how equivalent functionality to systemd will be provided.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #195 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: 727708@bugs.debian.org

Subject: Strong argument for OpenRC

Date: Wed, 30 Oct 2013 15:52:29 +0800

Hi,

I got a *new* argument in the favor of OpenRC:

http://youtu.be/zoNoi8BgQjs

Yes, we made it work in Debian GNU/kFreeBSD! :)

Upstream was very friendly helping to do this last night and this
morning. Now, the next blocker would be renaming /sbin/rc to
/sbin/openrc, though upstream pretends it shouldn't be hard to do, and
they told me they will work on it. I unfortunately (and of course, I'd
say) can't upload to Debian until this is fixed, though it's in
collab-maint for those who want to try.

I warmly welcome Hurd folks to try porting it too.

Thomas Goirand (zigo)

Message #200 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <wouter@debian.org>

To: Wouter Verhelst <wouter@master.debian.org>, 727708@bugs.debian.org, Russ Allbery <rra@debian.org>, Lucas Nussbaum <leader@debian.org>, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 30 Oct 2013 12:27:20 +0100

[Message part 1 (text/plain, inline)]

Op 29-10-13 09:26, Steve Langasek schreef:
> I see no reason that, if upstart were chosen as the default, porters could
> not use it for our non-Linux ports as well.

With some work, sure.

> This is a much better outcome
> across our distribution as a whole than to require developers to continue
> maintaining init scripts just for our non-Linux ports.

I did not say "require", I said "encourage". I agree that it's
unreasonable to expect developers to maintain init scripts that they
themselves do not use in addition to init configuration for whatever
init system we end up with; and I do agree that it should be fair game
for people to drop the init script from their package.

However, there are some advantages to be had in continue to ship init
scripts (while I can see no downsides, apart from the fact that they
need to be written), and in that light it can make sense for us to
encourage people to continue shipping init scripts.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/

[signature.asc (application/pgp-signature, attachment)]

Message #205 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Helmut Grohne <helmut@subdivi.de>

To: 727708@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 30 Oct 2013 15:10:16 +0100

Hi Steve,

On Tue, Oct 29, 2013 at 09:31:37AM -0700, Steve Langasek wrote:
> On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote:
> > Having read the parts of the ctte bug, it feels odd to preclude the
> > option of supporting multiple init systems from discussion or
> > consideration. If Debian is to support only one init system and that one
> > init system is systemd, then given my above analysis it will be very
> > hard for non-Linux ports to catch up. I argue that in this case we
> > should consider dropping support for non-Linux ports. So if we really
> > are considering such an outcome, why not consider the outcome of
> > supporting multiple init systems (but maybe only one per architecture)?
> 
> While other members of the TC may wish to consider this option, I've ruled
> it out myself because we would lose most of the benefits of switching away
> from sysvinit and instead accrue significant maintenance costs to individual
> developers who would then have to support both init systems in their
> packages.  What makes switching init systems worth doing is being able to
> *simplify* the interfaces between the init system and the services.
> Continuing to support different init systems across different architectures
> would add complexity instead.  That's a pretty bleak outcome.

I fully agree with your reasoning. Yet, I see that the options
 * drop support for non-Linux ports and
 * maintain some support for an alternate init system
are similarly painful. I see neither of them a desirable, but if we
really consider one of them, I'd ask for the other one to be considered
and evaluated as well.

Most participants in this thread appear to agree that the sysvinit
*interface* for services (shell scripts) is suboptimal. We are currently
mostly arguing about implementations, because each proposed interface
has only one implementation. It might make sense to consider a subset of
the interface that one implementation provides as our standard and
provide a degraded experience to that interface on non-Linux ports. For
example, if systemd were to be the init system of choice, it could be
required to provide an init script for services with Type=notify.

The interfaces of all init systems (except sysvinit, but are we really
considering that one?) still are somewhat in flux, so this is the point
where we can still influence and shape them.

<dream>
Imagine a world where upstart and systemd would use the same syntax
(structure) but implement different and somewhat overlapping aspects.
Maybe 50% of the daemons would work with either of them without needing
changes. <wakeup/> But now we call it "exec" here and "ExecStart" there,
"export" here and "Environment" there, and "chdir" here and
"WorkingDirectory" there. Bummer.
</dream>

Oh wait, I am talking to one of the guys who can actually fix this. :)

> > This would become radically easier if gnome were to become Architecture:
> > linux-any.
> 
> GNOME may be the trigger for this being raised to the TC, but it's not the
> core question that we need to address.

Even though I did mention gnome over there, the argument is not
restricted to gnome in any way. It can be applied to any other package
not deemed worthy to support on non-Linux ports (and I should have made
this explicit). Furthering this thought leads to turning non-Linux ports
into derivatives as presented by others in this thread.

I argue that a resolution of this bug needs to answer:

  What is going to happen with non-Linux ports?

Helmut

Message #210 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <wouter@debian.org>

To: debian-devel@lists.debian.org

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 30 Oct 2013 16:29:24 +0100

Op 30-10-13 00:16, Russ Allbery schreef:
> Carlos Alberto Lopez Perez <clopez@igalia.com> writes:
>> On 28/10/13 20:14, Christoph Anton Mitterer wrote:
> 
>>> For those who haven't seen it, Lennart has posted some of his comments
>>> about all this on G+:
>>> https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf
> 
>> And here is the reply from Gentoo developer Patrick Lauer:
> 
>> http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt
> 
> This, sadly, was not particularly useful or interesting.

I disagree. His point isn't argued very well (seems more like a rant
than a discussion), but it's there.

> As near as I can
> tell, the core content was that he doesn't think cgroup management is
> particularly difficult (fine, but I don't think that was the point; the
> point, instead, was that it's important to have a single arbitrator, which
> if true poses specific technical challenges) and he believes that the
> components to systemd would be easy to implement as separate daemons if
> they were properly documented.
> 
> I'm one of those people who thinks that nearly everything in Linux is
> horribly underdocumented, so I'm not going to argue with that point, but
> it's not a very useful statement from a practical viewpoint.  systemd
> offers specific pieces of integrated functionality.  By and large, no one
> seems to question that the operations enabled by that functionality are
> useful (although there is some debate over how useful).  GNOME is not
> depending on systemd out of some nefarious plot.  It's depending on
> systemd because GNOME wants to use those pieces of functionality systemd
> provides.
> 
> Therefore, I think it's important for arguments against using systemd to
> somehow engage directly with the questions about functionality.  Either
> there needs to be an argument that the functionality is not important and
> can be done without (which raises questions about how one would build
> GNOME in such an environment), or there needs to be some sort of plan for
> how equivalent functionality to systemd will be provided.

From the above link:

"The only thing stopping me from reimplementing that functionality is
that I have no idea what it's supposed to *do* ... and I don't enjoy
reading through all of systemd to find out."

(about logind)

While I agree with your point, it's pretty difficult to reimplement the
"interesting" parts of systemd in other implementations of pid1 if
whoever wrote the "interesting" parts does not document it, does not say
what it's supposed to do, does not want to accept patches for things
they're not interested in, and is by and large uninterested in anyone
who prefers to use something else than whatever their kool-aid is.

I'll grant that maybe logind provides interesting functionality which
other projects might want to depend on, and that there's nothing wrong
with that. The problem, however, is that the functionality is not
defined: if I want to provide an alternative pid1 implementation, then
the specifications are clear, and I should Just Do It (not that I'm
going to muddle the waters even more by doing so, but you understand the
point). If I want to provide an alternative implementation of logind,
however, then the only spec out there is the logind code, which might
change one day to the next just because the logind developer feels like it.

This wouldn't be much of a problem if I could just take logind (and
udev, and dbus, and more things) out of the systemd source tree and use
it without systemd, should I want to. But you can't; the problem is that
the upstream of all these projects is by and large uninterested in doing
so, and also does not seem to support other people who are, and at least
the Debian maintainers of systemd have gone on record as saying that
they won't guarantee this would remain possible (if the systemd
developers would be willing to do so, then I suppose that could
ameliorate some concerns).

The "obvious" solution would be that the world changes to systemd
because what, essentially, amounts to a level of sabotage by the systemd
developers of things that aren't systemd. If systemd is in fact the best
choice "out there", of which I'm not convinced at this point in time,
then I wouldn't mind that (much). But I'd like us to do so for the right
technical reasons, not just because it means we make our lives easier in
not having to fight with a stubborn upstream all the time. We could,
after all, fork, like we have done on other occasions of stubborn upstreams.

Given all of the above, I would even argue that perhaps Debian should
*not* adopt systemd as init system, out of principle; if we were to do
so, then almost all the major distributions would be using systemd (with
the sole exception of Ubuntu; I expect redhat to switch to systemd for
their next EL version), which could go a long way to making it part of
what it means to be running "Linux". At that point, any competing
innovative implementations would simply face an almost insurmountable
heap of undocumented code.

Yes, absense of documentation is common on Unix and Linux systems; but
no, I do not think that this is okay, or that we should in any way
encourage that sort of thing.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/

Message #215 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>

To: 727708@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 30 Oct 2013 15:52:46 +0100

On Wed, Oct 30, 2013 at 03:10:16PM +0100, Helmut Grohne wrote:
> The interfaces of all init systems (except sysvinit, but are we really
> considering that one?) still are somewhat in flux, so this is the point
> where we can still influence and shape them.
> 
> <dream>
> Imagine a world where upstart and systemd would use the same syntax
> (structure) but implement different and somewhat overlapping aspects.
> Maybe 50% of the daemons would work with either of them without needing
> changes. <wakeup/> But now we call it "exec" here and "ExecStart" there,
> "export" here and "Environment" there, and "chdir" here and
> "WorkingDirectory" there. Bummer.
> </dream>
Hi Helmut,
"exec" vs. "ExecStart=" and "export" vs. "Environment=" is easy.
Anyone can whip up a sed script to convert between those. The question
is how to deal with more advanced options. Let's say that I have a
systemd unit with

CapabilityBoundingSet=CAP_SYS_TIME    # limit the capability bounding set to CAP_SYS_TIME
PrivateTmp=yes                        # run with unshared /tmp
InaccessibleDirectories=/home	      # run without access to /home
WatchdogSec=60			      # consider the service dead if it hasn't pinged the
                                      # manager for in the last minute
Restart=on-failure                    # restart service on watchdog failure or unclean exit

This isn't a question of syntax, it's a question of significant
functionality in the manager. I think that sharing service
descriptions between disparate init managers is infeasible, unless we
forbid the use of anything but the basic features.

Another thing that is turning into a significant gap is socket
activation.  In systemd, socket activation allows the service to
receive multiple open sockets (e.g. ports 80 and 443 for an httpd
server). Socket activation of daemons is cool:
- it is very easy to write such a daemon, it must just do accept(), read() and write()
- resource efficent because of activation on demand
- great for running unpriviledged, since the daemon only does accept(), read() and write()
- we get rid of a lot of inter-daemon ordering dependencies.
With the recent addition of (experimental) systemd-socket-proxyd[1],
even daemons like apache which do not support socket activation
internally can be launched on demand by wrapping them with a
helper. Socket activation is a great technique, bound to be used more.
Achieving the same functionality with init scripts is very
hard, and AFAIK, upstart doesn't support socket activation with
more than one socket.

[1] http://www.freedesktop.org/software/systemd/man/systemd-socket-proxyd.html

> Oh wait, I am talking to one of the guys who can actually fix this. :)

Zbyszek

Message #220 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: debian-devel@lists.debian.org

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 30 Oct 2013 16:58:36 +0100

]] Wouter Verhelst 

> Yes, absense of documentation is common on Unix and Linux systems; but
> no, I do not think that this is okay, or that we should in any way
> encourage that sort of thing.

By absense of documentation, are you referring to the almost 10% of the
source base that are comments or the 15% that is DocBook XML based
documentation?  (Almost 14kLOC and almost 36kLOX, respectively.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #225 received at 727708-quiet@bugs.debian.org (full text, mbox, reply):

From: Thorsten Glaser <tg@mirbsd.de>

To: debian-devel@lists.debian.org

Cc: 727708-quiet@bugs.debian.org

Subject: Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 30 Oct 2013 16:05:48 +0000 (UTC)

Steven Chamberlain dixit:

[…]
>substitute Upstart here if you prefer), each package's maintainer could:
[…]

* Write scripts for one system and generate the other from it
or even
* Write “Debian init declaration” and let something take care
  of generating an initscript and whatever the other systems
  use out of it

bye,
//mirabilos
-- 
<hecker> cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten
die nicht noch 3 Jahre warten können? <mirabilos> bis dahin gibts google nicht
mehr <hecker> ja, könnte man meinen. wahrscheinlich ist der angekündigte welt-
untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum
müssen die die doodles vorher noch raushauen

Message #230 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Игорь Пашев <pashev.igor@gmail.com>

To: 727708@bugs.debian.org, Debian Devel <debian-devel@lists.debian.org>

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 30 Oct 2013 20:59:00 +0400

2013/10/30 Helmut Grohne <helmut@subdivi.de>:
> What is going to happen with non-Linux ports?

Debian is not Debian without non-Linux ports.

As for me, I think it is not very hard to maintain diffrent init
systems for different kernels.
Especially if Debian GNU/Linux get rid of sysvinit: writing systemd or upstrart
services is simple (as well as SMF).

Just one example from OSDyson (lighttpd):

1. dh-smf: http://cgit.osdyson.org/dh-smf.git
2. lighttpd depends on dh-smf for illumos kernel:
http://cgit.osdyson.org/lighttpd.git/tree/debian/control#n10
3. No changes in d/rules (!):
http://cgit.osdyson.org/lighttpd.git/tree/debian/rules
4. DH automatically peeks up dh_smf:
http://cgit.osdyson.org/debhelper.git/tree/dh?id=3769023faf4758f944e710480c43cda220821690#n524
5. dh_smf looks into this directory:
http://cgit.osdyson.org/lighttpd.git/tree/debian/lighttpd.smf
6. dh_installinit is no-op on Dyson

Message #235 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Wouter Verhelst <wouter@debian.org>, 727708@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 30 Oct 2013 10:56:07 -0700

[Message part 1 (text/plain, inline)]

On Wed, Oct 30, 2013 at 04:29:24PM +0100, Wouter Verhelst wrote:
> While I agree with your point, it's pretty difficult to reimplement the
> "interesting" parts of systemd in other implementations of pid1 if
> whoever wrote the "interesting" parts does not document it, does not say
> what it's supposed to do, does not want to accept patches for things
> they're not interested in, and is by and large uninterested in anyone
> who prefers to use something else than whatever their kool-aid is.

> I'll grant that maybe logind provides interesting functionality which
> other projects might want to depend on, and that there's nothing wrong
> with that. The problem, however, is that the functionality is not
> defined: if I want to provide an alternative pid1 implementation, then
> the specifications are clear, and I should Just Do It (not that I'm
> going to muddle the waters even more by doing so, but you understand the
> point). If I want to provide an alternative implementation of logind,
> however, then the only spec out there is the logind code, which might
> change one day to the next just because the logind developer feels like it.

Are there things missing from
<http://www.freedesktop.org/wiki/Software/systemd/logind/> from an
implementor's perspective?

For my part I regard this as a tempest in a teapot.  Lennart has been
effective at making people worry that not using systemd is too dangerous to
consider.  But Ubuntu has done just fine with splitting the dbus services
off of init up through systemd 204, and while we know there are some big
issues on the horizon with the cgroup manager and kdbus questions, these are
not settled matters across the Free Software ecosystem.  There are lots of
other people besides the upstart and Debian non-Linux-port community who
have reservations about the systemd gravity well, including anyone using
cgroups today on top of lxc or using the Google tools.

So I'm not going to give anyone a roadmap today for how these capabilities
will be made available in a non-systemd environment, because a lot of this
has to do with decisions that need to be made in the relevant wider
technical communities and have nothing to do with the init system per se.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #240 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Theodore Ts'o <tytso@mit.edu>

Cc: Wouter Verhelst <wouter@master.debian.org>, Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 30 Oct 2013 18:18:29 -0700

Theodore Ts'o <tytso@mit.edu> writes:
> On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:

>> Well, I've said this before, but I think it's worth reiterating.
>> Either upstart or systemd configurations are *radically better* than
>> init scripts on basically every axis.  They're more robust, more
>> maintainable, easier for the local administrator to fix and revise,
>> better on package upgrades, support new capabilities, etc.

> Can you please go in to more detail why you believe this was true?

I think it's painfully obvious if you compare an init script to an upstart
or systemd configuration file for a simple daemon like, say, my lbcd
package.

For those who don't agree, please try the exercise of writing systemd and
upstart configuration files for some typical daemon package and look at
the number of lines of code in both and the behavior in edge cases (daemon
already running, daemon running but with no PID file because something
else deleted it, daemon part of a dependency chain that shouldn't fire
until the daemon is actually listening to the network, correct exit status
for various failure conditions, stopping the daemon when there is a user
process with the same name as the daemon also running, and the other cases
Policy says one must handle).  Now compare the length of time it took you
to make an init script correctly handle all those cases versus how long it
took to write the upstart or systemd configuration.  (Note that I have
found, IIRC, two different edge-case bugs in /etc/init.d/skeleton while
working on Debian, so even if you start from that file, which is only
applicable to a relatively narrow range of circumstances, you can still
fail edge cases.)

I have prior experience here both as Policy editor dealing with the Policy
sections related to init scripts and as a Lintian maintainer dealing with
Lintian checks for init scripts.  Both of those experiences were, shall we
say, convincing.

Another way to look at this is that both upstart and systemd provide a
high-level programming language for writing init scripts.  Not only does
it implement a higher level of abstraction, it's also better-suited to the
problem space because it's declarative rather than imperative.  (systemd
somewhat more so than upstart, although that makes it somewhat more
awkward to use in cases where you really need to run some shell script on
various actions.)

As with any move to a higher-level programming interface, there are
drawbacks; if you really want to do your own memory management, you don't
get to any more.  And as with most moves to a higher-level programming
interface well-suited to the task at hand, the advantages outweigh the
drawbacks.  (And in this case, I'd go a step farther and say that I think
most of the drawbacks people cite around loss of flexibility are at least
arguably benefits.  The world would be a better place with fewer init
scripts doing weird and unexpected things to paper over bugs better fixed
somewhere else.)

This really shouldn't be a particularly controversial stance.  Ever since
Solaris SMF, various UNIX implementations have been abandoning traditional
init scripts for exactly these reasons.  I really don't think that all
those completely independent technical teams, which at this point include
most major Linux distributions (counting OpenRC as another higher-level
implementation), are all wrong.

This is an area of personal interest of mine.  I followed daemontools
development back when Dan Bernstein was tackling this same basic problem
in his distinctively radical way, and have subsequently been paying at
least casual attention to various different daemon management facilities
ever since.  A lot of people have tried to solve various aspects of the
problem that init scripts are actually horrible at what they do, and the
solutions have been slowly improving and becoming more and more robust.

AFS attempted to solve this problem all the way back in the 1980s.  Even
back then, it was obvious that init scripts were insufficiently powerful
to manage production services properly, hence the whole bosserver system
that persists in OpenAFS to this day and which, coming from MIT, you may
be familiar with.  Not that I would advocate use of bosserver for anything
other than AFS these days, as there are now lots of newer technologies
that have surpassed it, although (relatively) secure network management of
services is still an interesting feature.

> The lsat time I played with Upstart, I saw a lot of policy moved from
> shell scripts into C code (which I would have to edit and recompile) if
> I wanted to change things.  I also was extremely frustrated with a
> massive lack of documentation, where at least with shell scripts I could
> read the scripts to understand what was going on.

I suspect you and I have a root disagreement over the utility of exposing
some of those degrees of freedom to every init script author, but if you
have some more specific examples of policy that you wanted to change but
couldn't, I'd be interested in examples.

Note that *Debian*, as a distribution, has a significant interest in
standardizing policy around how daemons are managed.  It's therefore not a
bad thing for the distribution if we have an init system that handles that
policy, provided that it encodes the policy that we want.  I realize that
the local administrator may have other goals, and they should have ways of
achieving them, but both systemd and upstart support running SysV init
scripts for those cases.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #245 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Theodore Ts'o <tytso@mit.edu>

To: Russ Allbery <rra@debian.org>

Cc: Wouter Verhelst <wouter@master.debian.org>, Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 30 Oct 2013 20:41:10 -0400

On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
> Well, I've said this before, but I think it's worth reiterating.  Either
> upstart or systemd configurations are *radically better* than init scripts
> on basically every axis.  They're more robust, more maintainable, easier
> for the local administrator to fix and revise, better on package upgrades,
> support new capabilities, etc.

Can you please go in to more detail why you believe this was true?

The lsat time I played with Upstart, I saw a lot of policy moved from
shell scripts into C code (which I would have to edit and recompile)
if I wanted to change things.  I also was extremely frustrated with a
massive lack of documentation, where at least with shell scripts I
could read the scripts to understand what was going on.

Maybe things have changed, but that was my impression with both
Systemd and Upstart (and policykit, and consolekit, etc. all of which
has caused me no end of frustration).

						- Ted

Message #250 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Theodore Ts'o <tytso@mit.edu>

To: Russ Allbery <rra@debian.org>

Cc: Wouter Verhelst <wouter@master.debian.org>, Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 30 Oct 2013 21:50:53 -0400

On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
> I suspect you and I have a root disagreement over the utility of exposing
> some of those degrees of freedom to every init script author, but if you
> have some more specific examples of policy that you wanted to change but
> couldn't, I'd be interested in examples.

It's not necessarily the init script author who might want the degrees
of freedom, but the local system administrator.

The most basic is the idea that whether you can control (via shell
scrpit fragments) whether or not a service should start at all, and
what options or environments should be enabled by pasing some file.
The fact that we can put that sort of thing in configuration files
such as /etc/default/*, for example.

Yes, yes, you can do this via if you use system V init scripts scripts
in backwards compatibility mode, but you've argued that we should be
moving briskly away from that.  In which case system administrators
will need to hand-edit the services files by hand, which will no doubt
increase the chances of conflicts at package upgrade time, compared to
if the configuration options were isolated away in files such as
/etc/default/rsync (for example).

> I realize that
> the local administrator may have other goals, and they should have ways of
> achieving them, but both systemd and upstart support running SysV init
> scripts for those cases.

If the package does not ship a SysV init script (which is your ideal
long-term outcome), that may not be very practical option for a system
adminsitrator who may need to recreate a SysV init script, especially
if the service file is rather complicated, or is using some of the
more advanced feature of systemd/upstart.

						- Ted

Message #255 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Theodore Ts'o <tytso@mit.edu>

Cc: Wouter Verhelst <wouter@master.debian.org>, Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 30 Oct 2013 19:13:04 -0700

Theodore Ts'o <tytso@mit.edu> writes:
> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:

>> I suspect you and I have a root disagreement over the utility of
>> exposing some of those degrees of freedom to every init script author,
>> but if you have some more specific examples of policy that you wanted
>> to change but couldn't, I'd be interested in examples.

> It's not necessarily the init script author who might want the degrees
> of freedom, but the local system administrator.

> The most basic is the idea that whether you can control (via shell
> scrpit fragments) whether or not a service should start at all, and what
> options or environments should be enabled by pasing some file.  The fact
> that we can put that sort of thing in configuration files such as
> /etc/default/*, for example.

> Yes, yes, you can do this via if you use system V init scripts scripts
> in backwards compatibility mode, but you've argued that we should be
> moving briskly away from that.  In which case system administrators will
> need to hand-edit the services files by hand, which will no doubt
> increase the chances of conflicts at package upgrade time, compared to
> if the configuration options were isolated away in files such as
> /etc/default/rsync (for example).

Ah, I see.

However, I do think this is mostly a solvable problem.  We should provide
meaningful flexibility in our init script configuration, which may include
providing hooks so that local administrators have a place to put that
local policy.

You're right that some of this functionality will probably be lost in the
initial conversion to something other than init scripts, but I would
consider that to (usually) be a bug, and as people report problems, we can
be sure it's added back in after understanding the issues involved.  Yes,
this may be a bit annoying for people in the short term, but I do think it
gets us to a better place in the long run by way of supporting clean and
documented interfaces for those policy settings.

It is true that currently init scripts are full-blown programs, allowing
anyone who is capable of programming in that language to make arbitrary
policy modifications.  We lose that by switching to a higher-level
language, and only policy decisions anticipated by that language will be
easily implemented.  More complex policy decisions would have to be
handled at a higher level, via selectively creating or removing the
configuration files.  It's certainly a disruptive change.  I'm not
convinced it's a net negative, but it will depend on how strong the
available hooks are and what types of policy the local administrator wants
to easily change.

I do think that being able to treat the init scripts as real configuration
files will make maintaining such local policy easier than it is currently.
The prospect of modifying init scripts was already dire enough that we
pushed most meaningful configuration into /etc/default instead of asking
that people change the complicated init scripts and then handle merges on
package upgrades.  *Most* local changes are fairly simple, and would only
require small and mergable changes to upstart configuration files, and
small overrides to systemd files.

I personally like upstart's model a little better, but systemd's model of
/etc overrides /lib is, I think, workable as long as people remember to
change only the setting they want and then include the original instead of
making copies of the whole configuration.  (That being said, I'm worried
about how the systemd model handles the common case of wanting to change
the command-line arguments to a daemon, and then having the package also
change the command-line arguments in some orthogonal way.)

> If the package does not ship a SysV init script (which is your ideal
> long-term outcome), that may not be very practical option for a system
> adminsitrator who may need to recreate a SysV init script, especially if
> the service file is rather complicated, or is using some of the more
> advanced feature of systemd/upstart.

You can do quite a bit with the hooks that are part of the specification
of both types of files.  For example, logic that you may add to control
whether the service should start at all can be implemented by adding a
pre-start stanza to the upstart configuration.

This particular action appears to be harder to do in systemd, which
doesn't, at least from the documentation that I've found, support running
arbitrary shell code to determine whether to start a unit, but there are a
bunch of other possible built-in checks.  I suppose one could also change
the command started to wrap it and put the check there, although that
feels quite ugly.

In general, upstart's integration with arbitrary actions in shell
fragments is considerably better than systemd's, at least based on the
documentation I've read.  upstart feels like it provides more useful
flexibility.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #260 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>

To: Theodore Ts'o <tytso@mit.edu>

Cc: Russ Allbery <rra@debian.org>, Wouter Verhelst <wouter@master.debian.org>, Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Thu, 31 Oct 2013 03:21:36 +0100

On Wed, Oct 30, 2013 at 09:50:53PM -0400, Theodore Ts'o wrote:
> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
> > I suspect you and I have a root disagreement over the utility of exposing
> > some of those degrees of freedom to every init script author, but if you
> > have some more specific examples of policy that you wanted to change but
> > couldn't, I'd be interested in examples.
> 
> It's not necessarily the init script author who might want the degrees
> of freedom, but the local system administrator.
> 
> The most basic is the idea that whether you can control (via shell
> scrpit fragments) whether or not a service should start at all, and
> what options or environments should be enabled by pasing some file.
> The fact that we can put that sort of thing in configuration files
> such as /etc/default/*, for example.
Both systemd and upstart support this well enough.

With systemd you can say EnvironmentFile=/etc/default/<whatever>
and use the variables in ExecStart=/path/to/prog $VAR1 $VAR2.
This is usually discouraged, not because it doesn't work, but
because it uses two files to provide very little value. In majority
of cases it turns out that the settings in /etc/default either
can't be changed in an useful way, or are better read by the daemon
itself from a different configuration file. But if you want this, then
it's there.

If the settings are to complicated for the declarative style, you
can always use an helper shell script to launch the daemon.
Again, discouraged, but certainly supported.

> Yes, yes, you can do this via if you use system V init scripts scripts
> in backwards compatibility mode, but you've argued that we should be
> moving briskly away from that.  In which case system administrators
> will need to hand-edit the services files by hand, which will no doubt
> increase the chances of conflicts at package upgrade time, compared to
> if the configuration options were isolated away in files such as
> /etc/default/rsync (for example).
Actually this doesn't happen that often. Typical systemd service file
has 1-3 lines of documentation, 1+ lines of ExecStart stuff, and a few
additional settings. They are mostly orthogonal, so you just override
the one you need. Probably most common case is to override ExecStart=,
done by adding the file like /etc/systemd/system/myservice.d/custom-start.conf
which only overrides ExecStart. Nice and simple, no conflicts on upgrade.

> > I realize that
> > the local administrator may have other goals, and they should have ways of
> > achieving them, but both systemd and upstart support running SysV init
> > scripts for those cases.
> 
> If the package does not ship a SysV init script (which is your ideal
> long-term outcome), that may not be very practical option for a system
> adminsitrator who may need to recreate a SysV init script, especially
> if the service file is rather complicated, or is using some of the
> more advanced feature of systemd/upstart.
Why would you recreate the whole script? Let the init manager take
care of starting and stopping and supervising, and only do the custom
stuff in the script. Then it should be just a few lines.

Zbyszek

Message #265 received at 727708@bugs.debian.org (full text, mbox, reply):

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

To: Theodore Ts'o <tytso@mit.edu>

Cc: Russ Allbery <rra@debian.org>, Wouter Verhelst <wouter@master.debian.org>, Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Thu, 31 Oct 2013 06:33:44 +0100

On 10/31/2013 02:50 AM, Theodore Ts'o wrote:
> The most basic is the idea that whether you can control (via shell
> scrpit fragments) whether or not a service should start at all, and
> what options or environments should be enabled by pasing some file.
> The fact that we can put that sort of thing in configuration files
> such as /etc/default/*, for example.
> 
> Yes, yes, you can do this via if you use system V init scripts scripts
> in backwards compatibility mode, but you've argued that we should be
> moving briskly away from that.  In which case system administrators
> will need to hand-edit the services files by hand, which will no doubt
> increase the chances of conflicts at package upgrade time, compared to
> if the configuration options were isolated away in files such as
> /etc/default/rsync (for example).

Ted, I'm sorry, but it's very obvious you have no clue how systemd is
supposed to be used. First of all, systemd - like udevd - supports
two places where to place systemd service files. One is located
below /usr/lib/systemd which is the directory where service files
provided by the package are placed, and one is /etc/systemd where
your own, custom service files are located.

If systemd finds an appropriate service file in /etc/systemd it will
ignore the appropriate service file in /usr/lib/systemd, always. So
there is never a problem with service files being overwritten during an
upgrade like you describe.

The same holds true, btw, for udevd with it's rules files which are
located in /lib/udev/rules.d and /etc/rules.d respectively.

And everything that you might want change in the configuration of
a service can be done by editing the service file and this in
a much easier and consistent way. Editing a file in the .ini
file format is a no-brainer which, in the worst mistake case, will
probably lead to an error message from the daemon or systemd while
messed up custom code may end up rendering your whole system unusable
if you are smart enough to mess up an rm command. Just have a look
at this wonderful bug in upstart [1].

> If the package does not ship a SysV init script (which is your ideal
> long-term outcome), that may not be very practical option for a system
> adminsitrator who may need to recreate a SysV init script, especially
> if the service file is rather complicated, or is using some of the
> more advanced feature of systemd/upstart.

No, System V Init scripts are not ideal on the long-term outcome since
they are highly distribution-specific, error-prone and annoying to
maintain. We have had tons of bugs in the bug tracker because of
broken init scripts, like this one [2].

I don't understand why anyone would think that having to write a small
piece of code to start another program is a sensible and good design,
especially when this is done for dozens of programs (= daemons) in very
much the same way. It absolutely makes sense to encode the logic to
start and control a daemon through a single piece of C code rather
than writing more-or-less the same bash script for every
single daemon on your machine.

Adrian

> [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177
> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668890

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Message #270 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: debian-devel@lists.debian.org

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Thu, 31 Oct 2013 06:39:53 +0100

]] Russ Allbery 

(Cleaned up the Cc line somewhat)

> You can do quite a bit with the hooks that are part of the specification
> of both types of files.  For example, logic that you may add to control
> whether the service should start at all can be implemented by adding a
> pre-start stanza to the upstart configuration.

ExecStartPre=/bin/false

will make the service be considered failed.  The ExecStartPre line can
of course be an executable that implements more checking or logic.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #275 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Theodore Ts'o <tytso@mit.edu>, 727708@bugs.debian.org

Cc: Russ Allbery <rra@debian.org>, Wouter Verhelst <wouter@master.debian.org>, Lucas Nussbaum <leader@debian.org>, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Thu, 31 Oct 2013 01:41:53 -0700

[Message part 1 (text/plain, inline)]

On Wed, Oct 30, 2013 at 08:41:10PM -0400, Theodore Ts'o wrote:
> On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
> > Well, I've said this before, but I think it's worth reiterating.  Either
> > upstart or systemd configurations are *radically better* than init scripts
> > on basically every axis.  They're more robust, more maintainable, easier
> > for the local administrator to fix and revise, better on package upgrades,
> > support new capabilities, etc.

> Can you please go in to more detail why you believe this was true?

> The lsat time I played with Upstart, I saw a lot of policy moved from
> shell scripts into C code (which I would have to edit and recompile)
> if I wanted to change things.

I'm surprised by this comment.  Very little policy is actually encoded in
upstart's C code; in fact, the only policy I can think of offhand that is is
some basic stuff around filesystems, which, aside from some must-have kernel
filesystems without which it can't boot the rest of the system, should be
entirely overrideable via /etc/fstab.  Perhaps you could expand on what
policies you saw a need to change?

> I also was extremely frustrated with a massive lack of documentation,
> where at least with shell scripts I could read the scripts to understand
> what was going on.

There's an awful lot of documentation available for upstart, but of course
people look for documentation in lots of different ways and we aren't
necessarily presenting the documentation where and when we need it.  There's
comprehensive documentation available at
<http://upstart.ubuntu.com/cookbook/>, but from context it's possible that's
not what you were looking for.  Aside from adding links to manpages to all
of the upstart jobs themselves (which I don't think is reasonable), are
there things you think should be done to make the right documentation easy
to find?  (For starters, what were you trying to find documentation of?)

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #280 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <wouter@debian.org>

To: Theodore Ts'o <tytso@mit.edu>

Cc: Russ Allbery <rra@debian.org>, Wouter Verhelst <wouter@master.debian.org>, Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Thu, 31 Oct 2013 09:54:10 +0100

Op 31-10-13 02:50, Theodore Ts'o schreef:
> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
>> I suspect you and I have a root disagreement over the utility of exposing
>> some of those degrees of freedom to every init script author, but if you
>> have some more specific examples of policy that you wanted to change but
>> couldn't, I'd be interested in examples.
> 
> It's not necessarily the init script author who might want the degrees
> of freedom, but the local system administrator.
> 
> The most basic is the idea that whether you can control (via shell
> scrpit fragments) whether or not a service should start at all, and
> what options or environments should be enabled by pasing some file.
> The fact that we can put that sort of thing in configuration files
> such as /etc/default/*, for example.

This, in my opinion, is one of the worst abominations we currently have
in Debian.

Whether an init script should run at boot time has no relation
whatsoever to whether it should run when the system administrator calls
it manually. Yet, with "ENABLE=" variables in /etc/default, this is
related, because the initscript will say "I'm disabled, go edit this
file if you want to start me", even if you just want to start a daemon
just this once manually, for testing.

AIUI, both upstart and systemd have configuration options where you can
tell the system that this particular service should not start at boot;
that will then, however, not affect the result when one manually tries
to start the service.

I'm not sure that's a very good argument ;-)

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/

Message #285 received at 727708@bugs.debian.org (full text, mbox, reply):

From: David Härdeman <david@hardeman.nu>

To: 727708@bugs.debian.org

Cc: leader@debian.org

Subject: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Thu, 31 Oct 2013 11:55:41 +0100

Dear Committee members,

I'm not a DD, just a random contributor, and I haven't been actively 
involved in the init system debate at all, nor do I have any stake in 
it, though I've followed it with some interest.

Now that the question has been referred to the Technical Committee 
(which seems reasonable given the lack of progress in the discussion so 
far), it strikes me as somewhat odd that the issue of impartiality/bias 
hasn't been discussed in the committee to this point.

The issue has already been raised on the Debian mailing lists[1] and 
externally[2][3].

The aphorism "Not only must Justice be done; it must also be seen to be 
done" [4], which is oft quoted, not only in judicial proceedings, but 
also in domestic tribunals (which would probably best describe the 
committee), is based on the principle that the mere appearance of bias 
(as opposed to actual bias which can be shown to have influenced a 
decision) is sufficient to taint the process/decision.

I would expect that a discussion that leads up to a decision on the 
technical issues would at least address the question of bias as well. 
Please note that I'm *not* trying to start a flame war here, and I'm 
*not* accusing anyone, but I'm afraid that any discussion (and decision) 
which was completely silent with regard to bias, once the question has 
been raised, would appear to be lacking and would undermine public 
confidence in the decision itself (and that's also the reason I bring 
this up on a public list rather than in private email).

Kind regards,
David Härdeman

[1] http://lists.debian.org/debian-devel/2013/10/msg00963.html
[2] 
http://slashdot.org/story/13/10/28/1621219/debian-to-replace-sysvinit-switch-to-systemd-or-upstart
[3] http://www.phoronix.com/scan.php?page=news_item&px=MTQ5NzQ
[4] http://en.wikipedia.org/wiki/R_v_Sussex_Justices,_ex_parte_McCarthy

Message #290 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@ayous.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Thu, 31 Oct 2013 12:06:26 +0100

* Russ Allbery (rra@debian.org) [131031 02:19]:
> Theodore Ts'o <tytso@mit.edu> writes:
> > On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
> 
> >> Well, I've said this before, but I think it's worth reiterating.
> >> Either upstart or systemd configurations are *radically better* than
> >> init scripts on basically every axis.  They're more robust, more
> >> maintainable, easier for the local administrator to fix and revise,
> >> better on package upgrades, support new capabilities, etc.
> 
> > Can you please go in to more detail why you believe this was true?
> 
> I think it's painfully obvious if you compare an init script to an upstart
> or systemd configuration file for a simple daemon like, say, my lbcd
> package.

For simple packages we would be far better of with a simple snippet
that is either used by programms like systemd or upstart directly, or
converted to a script by dh_initsnippet. One way or another we should
as you write below go to an higher level language for init scripts.


> Note that *Debian*, as a distribution, has a significant interest in
> standardizing policy around how daemons are managed.  It's therefore not a
> bad thing for the distribution if we have an init system that handles that
> policy, provided that it encodes the policy that we want.  I realize that
> the local administrator may have other goals, and they should have ways of
> achieving them, but both systemd and upstart support running SysV init
> scripts for those cases.

Also I think we should make sure that the init system we use doesn't
make it unnecessarily hard for local system administrators to change
local defaults.



Andi

Message #295 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Theodore Ts'o <tytso@mit.edu>

To: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>, Wouter Verhelst <wouter@master.debian.org>, Lucas Nussbaum <leader@debian.org>, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Thu, 31 Oct 2013 07:20:12 -0400

On Thu, Oct 31, 2013 at 01:41:53AM -0700, Steve Langasek wrote:
> I'm surprised by this comment.  Very little policy is actually encoded in
> upstart's C code; in fact, the only policy I can think of offhand that is is
> some basic stuff around filesystems, which, aside from some must-have kernel
> filesystems without which it can't boot the rest of the system, should be
> entirely overrideable via /etc/fstab.  Perhaps you could expand on what
> policies you saw a need to change?

The details are a bit fuzzy, because this was a quite a while ago,
when Upstart was first introduced into Ubuntu, and it was so
frustrating that it was what caused me to abandon Ubuntu and switch
back to Debian.  The high bit was I couldn't get a particular service
to start (it might have been bind, or some such), and I had no idea
how to debug the darned thing.  With shell scripts, it's possible to
insert "echo debug 1 $variable >> /tmp/debug.log" to figure out what's
going on.  With upstart, I had no way of figuring out what was going
on, and why it was failing, and the "no user-serviceable parts inside"
was extremely frusrtating.

I'm sure part of the problem was lack of documentation.  That seems to
be a common theme with many of these "higher level language" systems.
They may be powerful if you know the magic XML file to edit (in the
case of policy kit), but it took me several hours before I figured out
even something as simple as "say 'yes' to for all authorization
questions", which is how I still run to this day, because (a) the
default of prompting for the root password in popup windows all the
time was too painful, and (b) trying to figure out how to XML
language, and all of the triggeers, etc., was ***far*** too painful.
One of the nice things about shell scripts is that they are far more
self-documenting, and easier to debug, than XML and other
'higher-level' configuration files (at least for this dumb kernel
hacker :-).

So hopefully that is something the technical committee will take into
account --- how well things are documented, both in terms of a
comprehensive reference manual, and a tutorial that helps people with
common things that system administrators might want to do.  The
docuementation you pointed to at http://upstart.ubuntu.com/cookbook/
is something I wish I had access to when I first was forced to use
Upstart; maybe if Upstart was as polished back then, I might not have
given up on Ubuntu in disgust.

Regards,

					- Ted

Message #300 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: Theodore Ts'o <tytso@mit.edu>

Cc: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>, Wouter Verhelst <wouter@master.debian.org>, Lucas Nussbaum <leader@debian.org>, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Thu, 31 Oct 2013 12:09:05 +0100

* Theodore Ts'o:

> The most basic is the idea that whether you can control (via shell
> scrpit fragments) whether or not a service should start at all, and
> what options or environments should be enabled by pasing some file.

Curiously, a lot of system administrators do not do this correctly
using sysvinit, causing system daemons to start unexpectedly after
installing package updates.

I hope that a new init system will finally allow us to have something
like chkconfig (not the best name in the world, I admit) that works
reliably.

Message #305 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 727708@bugs.debian.org

Cc: Tollef Fog Heen <tfheen@debian.org>, Michael Biebl <biebl@debian.org>, Marco d'Itri <md@linux.it>, Thomas Goirand <zigo@debian.org>, Steve Langasek <vorlon@debian.org>, Steven Chamberlain <steven@pyro.eu.org>, Patrick Lauer <patrick@gentoo.org>, Alexander Vershilov <qnikst@gentoo.org>, Josselin Mouette <joss@debian.org>

Subject: Re: Bug#727708: init system question before the technical committee

Date: Thu, 31 Oct 2013 15:01:03 +0000

Ian Jackson writes ("Bug#727708: init system question before the technical committee"):
> Steve Langasek writes[1]:
> >   https://wiki.debian.org/Debate/initsystem/systemd
...
> So I would appreciate it if you (and by "you" I mean each side of the
> argument) would make sure that your page represents the best case you
> can put forward.

This seems to have come along very well in the past few days.

We now have five camps with pages with substantial content:

  https://wiki.debian.org/Debate/initsystem/multiple
  https://wiki.debian.org/Debate/initsystem/openrc
  https://wiki.debian.org/Debate/initsystem/systemd
  https://wiki.debian.org/Debate/initsystem/sysvinit
  https://wiki.debian.org/Debate/initsystem/upstart

Obviously people will need some time to further flesh this out and
particularly to write rebuttals (or incorporate points into their main
text which amount to rebuttals).

If you're in one of these camps you'll probably want to subscribe to
the pages of the others, so you can follow what they're doing and make
sure to respond appropriately.

How long do people think finalising this is going to take ?  There are
some potential problems with setting a hard deadline in advance but
we're hoping to deal with this matter fairly soon now.

Perhaps it would be good if the camp leader(s) for each camp would
reply with a summary of:
  - the status of their own main arguments: are you mostly done,
     or do you expect to add more substantial points
  - the status of their rebuttals: subject of course, to any future
     changes by the other camps, how close are you to having what
     you consider a good answer to the other camps' points ?

Thanks,
Ian.

Message #310 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: David Hardeman <david@hardeman.nu>, 727708@bugs.debian.org

Cc: leader@debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Thu, 31 Oct 2013 15:17:38 +0000

David Härdeman writes ("Bug#727708: tech-ctte: Decide which init system to default to in  Debian."):
> I'm not a DD, just a random contributor, and I haven't been actively 
> involved in the init system debate at all, nor do I have any stake in 
> it, though I've followed it with some interest.
> 
> Now that the question has been referred to the Technical Committee 
> (which seems reasonable given the lack of progress in the discussion so 
> far), it strikes me as somewhat odd that the issue of impartiality/bias 
> hasn't been discussed in the committee to this point.

Several of the messages on debian-devel in the init system GR proposal
thread on -devel have discussed this.  Please read that thread, which
has comments from a number of TC members on this question.

I don't think there would be any value in formally addressing this as
part of the TC resolution on the init system question.  If nothing
else, it would be rather circular to have people voting on whether to
disqualify each other.  There is a clear constitutionally defined
process for excluding some TC members from voting on some matters,
which does not apply in the current situation.

If your concern is just that those messages from TC members aren't
"[discussion] in the committee" as you put it, I think simply
repeating the earlier messages, as postings to this bug, doesn't seem
to have much value.

But just for reference here are the urls I found of the contributions
from TC members and (ex-)DPLs on the subject of bias:
  http://lists.debian.org/debian-devel/2013/10/msg00692.html
  http://lists.debian.org/debian-devel/2013/10/msg00747.html
  http://lists.debian.org/debian-devel/2013/10/msg00777.html
  http://lists.debian.org/debian-devel/2013/10/msg00699.html
  http://lists.debian.org/debian-devel/2013/10/msg00702.html
  http://lists.debian.org/debian-devel/2013/10/msg00818.html
  http://lists.debian.org/debian-devel/2013/10/msg00946.html
  http://lists.debian.org/debian-devel/2013/10/msg01014.html

And generally on democracy vs technogracy (if I may put it like that):
  http://lists.debian.org/debian-devel/2013/10/msg00996.html
  http://lists.debian.org/debian-devel/2013/10/msg00821.html
  http://lists.debian.org/debian-devel/2013/10/msg00830.html

Ian.

Message #315 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 727708@bugs.debian.org, Tollef Fog Heen <tfheen@debian.org>, Michael Biebl <biebl@debian.org>, Marco d'Itri <md@linux.it>, Thomas Goirand <zigo@debian.org>, Steve Langasek <vorlon@debian.org>, Steven Chamberlain <steven@pyro.eu.org>, Patrick Lauer <patrick@gentoo.org>, Alexander Vershilov <qnikst@gentoo.org>, Josselin Mouette <joss@debian.org>

Subject: Re: Bug#727708: init system question before the technical committee

Date: Thu, 31 Oct 2013 09:05:07 -0700

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> How long do people think finalising this is going to take ?  There are
> some potential problems with setting a hard deadline in advance but
> we're hoping to deal with this matter fairly soon now.

I propose the following approach:

1. Set a date for the first drafts of the various position papers to be
   finalized
2. Set a time period for the technical committee to review all of those
   papers and think about them and possibly have some discussion, and to
   produce a list of questions or concerns that don't feel adequately
   addressed
3. Give all of the position drafters an opportunity to further revise
   their positions based on feedback from that discussion
4. Have a vote based on those final position papers

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #320 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Konstantinos Margaritis <markos@freevec.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: init system question before the technical committee

Date: Thu, 31 Oct 2013 21:44:59 +0200

[Message part 1 (text/plain, inline)]

Hi all,

I'd just like to mentioned just a small(big? you decide) issue that I
haven't seen mentioned yet from anyone. Against systemd.

systemd has explicitly mentioned its Linux-only support. Sure, that
affects kFreeBSD/Hurd now. But changing an init system should be done
looking ahead *at least* 10 years (we've used the old one for 20+ and
in itself sysvinit exists for >30 years). Binding Debian to Linux *now*
will make it pretty certain that soon current non-Linux ports will
disappear, but also that potential *new* ports will never appear -or
will be extremely hard/unlikely to be integrated as well as these ones
have.

So I think this question should really be added as a con to systemd. To
be honest I'm indifferent, but if I had to, I'd choose either
OpenRC or upstart, and that would be one of the reasons for that. We
might not have a new port now, but I doubt anyone could foresee the
addition of kFreeBSD a year before. With a OS-agnostic init system, you
leave the option open, with systemd you don't. 

Anyway, enough ranting, I think I've made my point, I'm sure the
technical committee will make the proper choice. And -I also want to
say this- contrary to the claims, I see no bias involved, both Steve and
Colin are extremely well respected Debian Developers. I honestly trust
them they will do the proper *technically sound* choice.

Regards

Konstantinos

[Message part 2 (application/pgp-signature, inline)]

Message #325 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Konstantinos Margaritis <markos@freevec.org>, 727708@bugs.debian.org

Subject: Re: Bug#727708: init system question before the technical committee

Date: Thu, 31 Oct 2013 20:47:05 +0000

Konstantinos Margaritis writes ("Bug#727708: init system question before the technical committee"):
> So I think this question should really be added as a con to systemd.

The way that the Debate wiki system works is that the proponents of
any particular answer are in charge of the page on that answer.

So it is up to the systemd maintainers whether they want to discuss
this question on their page.  They do indeed mention it there,
although fairly briefly.  Of course the proponents of other approaches
can mention this on their page, as some of them do.

The Debate format does make it rather difficult to collect negative
views on a particular option.  Given how controversial systemd seems
to be (compared to the alternatives) I wonder though whether there is
a sufficient quorum of systemd naysayers to make it worth a separate
"anything but just systemd" camp.  There's nothing stopping such a
page being created, ideally by a team led by someone with experience
of working within and persuading Debian.

Ian.

Message #330 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Theodore Ts'o <tytso@mit.edu>, 727708@bugs.debian.org

Cc: Russ Allbery <rra@debian.org>, Wouter Verhelst <wouter@master.debian.org>, Lucas Nussbaum <leader@debian.org>, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Thu, 31 Oct 2013 14:07:20 -0700

[Message part 1 (text/plain, inline)]

On Thu, Oct 31, 2013 at 07:20:12AM -0400, Theodore Ts'o wrote:
> On Thu, Oct 31, 2013 at 01:41:53AM -0700, Steve Langasek wrote:
> > I'm surprised by this comment.  Very little policy is actually encoded in
> > upstart's C code; in fact, the only policy I can think of offhand that is is
> > some basic stuff around filesystems, which, aside from some must-have kernel
> > filesystems without which it can't boot the rest of the system, should be
> > entirely overrideable via /etc/fstab.  Perhaps you could expand on what
> > policies you saw a need to change?

> The details are a bit fuzzy, because this was a quite a while ago,
> when Upstart was first introduced into Ubuntu, and it was so
> frustrating that it was what caused me to abandon Ubuntu and switch
> back to Debian.  The high bit was I couldn't get a particular service
> to start (it might have been bind, or some such), and I had no idea
> how to debug the darned thing.  With shell scripts, it's possible to
> insert "echo debug 1 $variable >> /tmp/debug.log" to figure out what's
> going on.  With upstart, I had no way of figuring out what was going
> on, and why it was failing, and the "no user-serviceable parts inside"
> was extremely frusrtating.

Ah.  Sounds like you may have been hit by upstart's lack of logging support
for jobs at the time.  Upstart has supported logging of all output from jobs
(stderr,stdout) since 1.5, which was included in 12.04 LTS.  This was added
precisely because of that sort of frustrating experience you describe - an
experience that was shared not only by administrators, but also Ubuntu
developers trying to debug remaining corner cases in the init system
integration itself.

So on 12.04 and later, you just look at /var/log/upstart/$job.log to get the
debugging info you're looking for.  And if you need to debug upstart's own
state, you can boot with --verbose (or if necessary, --debug) to get useful
information dumped to kmsg - or turn this on with 'initctl log-priority
info' after boot.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #335 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Peter Dolding <oiaohm@gmail.com>

To: rra@debian.org

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Fri, 1 Nov 2013 14:42:51 +1000

Russ Allbery (rra@debian.org)

> In general, upstart's integration with arbitrary actions in shell
> fragments is considerably better than systemd's, at least based on the
> documentation I've read.  upstart feels like it provides more useful
> flexibility

This is in fact a extremely bad idea how it is implemented in upstart.

ExecStartPre=, ExecStartPost=,ExecReload=.... Kind of model in systemd
is better.

1 the upstart method you have to be watching the version of shell that
the scripts in the init system are using.   So we are back to the
sysvinit problem of update bash and hello stack of stuff don't start
any more.  ExecStartPre=/bin/bash somescript.sh

Think lets say I am a php or python developer.   Upstream.  Why do
they have to code there init items in bash or some other shell script.

The one property about systemd unit files that is extremely good is
there are no multi line commands.   Every command is a single line.

script
    # do some stuff
    if [ ... ]; then
        ...
    fi
end script

This pattern in upstart is in fact highly bad.

script
    # do some stuff
    if [ ... ]; then
        ...
    fi
end script

post-stop script
    # do some stuff
    if [ ... ]; then
        ...
    fi
end script

Think about this case.   While editing you by mistake delete something.

script
    # do some stuff
    if [ ... ]; then
        ...
    fi

post-stop script
    # do some stuff
    if [ ... ]; then
        ...
    fi
end script

See what missing.   Now your service start does something completely you wrong.

--script instead gives shell script code that will be executed using /bin/sh.--

Exactly what says that /bin/sh will be bash ash dash.....   Basically
you need to be able to declare interpreter of script.  Under sysvinit
you can declare interpreter of script.   systemd and openrc you can
also declare interpreter of script.   upstart has it hard coded.
This hard coded bit is bad.

systemd forces you to use many small shell files.  With systemd you
delete a line you take out a complete command.   You cannot mutate the
command todo something strange.

We are in a modern age of Languages there is no point taking in a init
system that forces the usage of one scripting interpreter that can
change and bring the system down.


Peter Dolding

Message #340 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Peter Dolding <oiaohm@gmail.com>

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Thu, 31 Oct 2013 21:51:39 -0700

Peter Dolding <oiaohm@gmail.com> writes:

> The one property about systemd unit files that is extremely good is
> there are no multi line commands.   Every command is a single line.

Yes, that's exactly what I think is obnoxious.  I prefer the upstart
syntax, which avoids the temptation to write unreadable one-line shell
constructs.  (Indeed, several have already been posted in recipes in
various threads on debian-devel about this.)  You can, of course, be
disciplined about this when writing systemd helper scripts by always
exernalizing the shell script into a separate file, but I really like that
upstart lets me inline trivial shell fragments without worrying about
that while still keeping them readable.

I personally don't find any of your other arguments persuasive (maybe I'm
too used to writing portable /bin/sh scripts), but I do see where you're
coming from.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #345 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Matthias Urlichs <matthias@urlichs.de>

To: 727708@bugs.debian.org

Subject: systemd vs. whatever

Date: Fri, 1 Nov 2013 14:03:06 +0000

IMHO.

Sorry, but SysV init scripts are an unfixable mess. The sooner we have
a system which does not have, let alone require, /etc/rc*, the better.

One non-feature of upstart which I happen to care strongly about is its
use of ptrace(2) to figure out what a job is doing. This destroys any
attempt to just use "strace foo" as the job, if one really needs to
figure out what a piece of software is doing wrong. Thanks but no
thanks.

One important feature of systemd, as Dracut has demonstrated on Fedora,
is to cleanly shutdown a complex system. The other init systems in
question do not support this feature. IMHO this is an essential
feature which we should have had ten years ago. At least.

Again IMHO, the perfect solution is to use systemd for Debian/Linux.
Non-Linux packages of Debian can simply steal ^w copy Gentoo's OpenRC
scripts.

(The additional effort packaging OpenRC scripts will be more than
 amortized the first time somebody finds a bug on Linux by simply
 running journalctl – instead of grepping through multiple syslog files,
 finding nothing, running the job under strace, and discovering that the
 daemonized code wrote its error message to stderr … which it previousy
 re-opened into /dev/null. Sounds familiar?)

On a more political note: the number of users of non-Linux Debian is …
let's admit it … tiny verging on negligible. While I do applaud their
proponents' efforts to build Debian userspace for alternate kernels, I
don't think it's fair for them to force us to stay with a technically
inferior solution.

-- 
-- Matthias Urlichs

Message #350 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>

To: Matthias Urlichs <matthias@urlichs.de>, 727708@bugs.debian.org

Subject: Value of reading other's position statements [was: systemd vs. whatever]

Date: Fri, 01 Nov 2013 15:43:40 +0000

Dear Mr. Urlichs,

You wrote:

> One non-feature of upstart which I happen to care strongly about is its
> use of ptrace(2) to figure out what a job is doing. This destroys any
> attempt to just use "strace foo" as the job, if one really needs to
> figure out what a piece of software is doing wrong. Thanks but no
> thanks.

Let me allow to quote the upstart's position statement:

> The systemd position statement asserts that you can't attach gdb to a
> process run by the init system. This is not true, and can only be
> speculation on the part of the systemd proponents: ptrace is only used
> during service startup, after which upstart detaches from the process
> (relying on ordinary waitpid() for notification of service exit). This
> means that for all intents and purposes, by the time you would actually be
> in a position to try to attach to the process with gdb, upstart will no
> longer be tracing it. For valgrind, it's true that this would be less
> straightforward to do as part of an upstart job. If there were widespread
> demand for solving this, it wouldn't be difficult; but this doesn't seem
> like something that has much practical impact. It's unlikely that someone
> using valgrind for debugging will need to debug via an upstart job or
> systemd unit, as opposed to running the service directly.

(Cf. https://wiki.debian.org/Debate/initsystem/upstart)

HTH, HAND
– Mirosław Baran

Message #355 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>

Cc: 727708@bugs.debian.org, Matthias Urlichs <matthias@urlichs.de>

Subject: Re: Bug#727708: Value of reading other's position statements

Date: Fri, 01 Nov 2013 09:30:22 -0700

Miroslaw Baran <miroslaw+c+debbugs@makabra.org> writes:
> You wrote:

>> One non-feature of upstart which I happen to care strongly about is its
>> use of ptrace(2) to figure out what a job is doing. This destroys any
>> attempt to just use "strace foo" as the job, if one really needs to
>> figure out what a piece of software is doing wrong. Thanks but no
>> thanks.

> Let me allow to quote the upstart's position statement:

That statement talks about attaching gdb later in the lifetime of the
process.  It doesn't address Matthias's point about running the daemon
itself under strace.

The issues discussed with valgrind here:

>> For valgrind, it's true that this would be less straightforward to do
>> as part of an upstart job. If there were widespread demand for solving
>> this, it wouldn't be difficult; but this doesn't seem like something
>> that has much practical impact. It's unlikely that someone using
>> valgrind for debugging will need to debug via an upstart job or systemd
>> unit, as opposed to running the service directly.

are, I believe, the same as the issues with strace, so I think this
position statement concedes that Matthias is correct and the use of ptrace
does prevent that particular use case.

I don't personally consider this a major issue, but it is a minor one.  I
have personally done exactly that (replaced the daemon invocation with one
run under strace -o /root/tmp/trace) to debug problems in the past.  You
can attach strace later, just like you can attach gdb later, but that
doesn't help if the problem you're trying to get a system call trace for
is during the daemon startup.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #360 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>, 727708@bugs.debian.org

Cc: Matthias Urlichs <matthias@urlichs.de>

Subject: Re: Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]

Date: Fri, 1 Nov 2013 16:31:30 +0000

Miroslaw Baran writes ("Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]"):
> You wrote:
> > One non-feature of upstart which I happen to care strongly about is its
> > use of ptrace(2) to figure out what a job is doing. This destroys any
> > attempt to just use "strace foo" as the job, if one really needs to
> > figure out what a piece of software is doing wrong. Thanks but no
> > thanks.
> 
> Let me allow to quote the upstart's position statement:

I have to say that I think that if we were to suggest that packages
should supply upstart configs, this should be done by having the
packages use the SIGSTOP protocol, not by having init ptrace them.

Using ptrace like this is a trick one would use if one didn't have the
source code.

Ian.

Message #365 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org

Cc: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>, Matthias Urlichs <matthias@urlichs.de>

Subject: Re: Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]

Date: Fri, 1 Nov 2013 10:04:31 -0700

[Message part 1 (text/plain, inline)]

On Fri, Nov 01, 2013 at 04:31:30PM +0000, Ian Jackson wrote:
> Miroslaw Baran writes ("Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]"):
> > You wrote:
> > > One non-feature of upstart which I happen to care strongly about is its
> > > use of ptrace(2) to figure out what a job is doing. This destroys any
> > > attempt to just use "strace foo" as the job, if one really needs to
> > > figure out what a piece of software is doing wrong. Thanks but no
> > > thanks.

> > Let me allow to quote the upstart's position statement:

> I have to say that I think that if we were to suggest that packages
> should supply upstart configs, this should be done by having the
> packages use the SIGSTOP protocol, not by having init ptrace them.

> Using ptrace like this is a trick one would use if one didn't have the
> source code.

I agree.  It would still require some fiddling to make 'expect stop' work
together with strace anyway, since upstart only cares about SIGSTOP raised
by upstart's child process, not by the grandchild; so if you actually need
upstart to know non-racily when the service is started you would need the
process under trace to SIGSTOP its own parent.  Not elegant, but possible.

Or if you don't need to worry about a non-racy startup for the service
you're testing, just omit the 'expect' stanza entirely.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #370 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org

Cc: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>, Matthias Urlichs <matthias@urlichs.de>

Subject: Re: Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]

Date: Fri, 1 Nov 2013 17:39:15 +0000

Steve Langasek writes ("Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]"):
> I agree.  It would still require some fiddling to make 'expect stop' work
> together with strace anyway, since upstart only cares about SIGSTOP raised
> by upstart's child process, not by the grandchild; so if you actually need
> upstart to know non-racily when the service is started you would need the
> process under trace to SIGSTOP its own parent.  Not elegant, but possible.

Perhaps upstart could be made somehow to spawn strace -p at the
appropriate moment.

stracing daemon startup (and indeed anything else which seems to be
malfunctioning) is a powerful tool that the competent but desperate
sysadmin will reach for in many situations.  Making it difficult is a
distinct downside for any init replacement.

Ian.

Message #375 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 727708@bugs.debian.org, Miroslaw Baran <miroslaw+c+debbugs@makabra.org>, Matthias Urlichs <matthias@urlichs.de>

Subject: Re: Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]

Date: Fri, 1 Nov 2013 11:42:24 -0700

[Message part 1 (text/plain, inline)]

On Fri, Nov 01, 2013 at 05:39:15PM +0000, Ian Jackson wrote:
> Steve Langasek writes ("Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]"):
> > I agree.  It would still require some fiddling to make 'expect stop' work
> > together with strace anyway, since upstart only cares about SIGSTOP raised
> > by upstart's child process, not by the grandchild; so if you actually need
> > upstart to know non-racily when the service is started you would need the
> > process under trace to SIGSTOP its own parent.  Not elegant, but possible.

> Perhaps upstart could be made somehow to spawn strace -p at the
> appropriate moment.

> stracing daemon startup (and indeed anything else which seems to be
> malfunctioning) is a powerful tool that the competent but desperate
> sysadmin will reach for in many situations.  Making it difficult is a
> distinct downside for any init replacement.

Sure; but I think the difficulty here is overstated.  strace and upstart
service readiness have adverse interactions with one another, but when
you're debugging a daemon you are unlikely to be doing so under conditions
where you are simultaneously worried about upstart service readiness races.

I agree with all of the technical critiques here, I just don't see that this
relatively minor issue, which can be documented and worked around (and
ultimately, fixed upstream), is something that should be driving Debian's
choice of init system.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #380 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org

Cc: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>, Matthias Urlichs <matthias@urlichs.de>

Subject: Re: Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]

Date: Fri, 1 Nov 2013 18:49:34 +0000

Steve Langasek writes ("Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]"):
> I agree with all of the technical critiques here, I just don't see that this
> relatively minor issue, which can be documented and worked around (and
> ultimately, fixed upstream), is something that should be driving Debian's
> choice of init system.

One of the reasons that people are worried about replacing the
venerable sysvinit, is that they fear the loss of useful (sometimes,
essential) debugging techniques - of which this is one.

Ian.

Message #385 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]

Date: Fri, 1 Nov 2013 12:15:15 -0700

[Message part 1 (text/plain, inline)]

On Fri, Nov 01, 2013 at 06:49:34PM +0000, Ian Jackson wrote:
> Steve Langasek writes ("Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]"):
> > I agree with all of the technical critiques here, I just don't see that this
> > relatively minor issue, which can be documented and worked around (and
> > ultimately, fixed upstream), is something that should be driving Debian's
> > choice of init system.

> One of the reasons that people are worried about replacing the
> venerable sysvinit, is that they fear the loss of useful (sometimes,
> essential) debugging techniques - of which this is one.

But that's an unwarranted fear here.  Sysvinit doesn't give you any way to
plug in strace without having the exact same kind of service readiness
problems - either you can background the strace invocation, and then the
process unblocks the flow of execution immediately and the init script may
exit before the service is actually working; or you keep strace in the
foreground, and the init script as a whole never backgrounds.  You have the
exact same choices in upstart; people are just less familiar with the
interfaces for doing so, and familiarity isn't a good reason to stick with
sysvinit indefinitely.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #390 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Matthias Urlichs <matthias@urlichs.de>

To: Russ Allbery <rra@debian.org>

Cc: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>, 727708@bugs.debian.org

Subject: Re: Bug#727708: upstart ./. ptrace, sockets, etc.

Date: Fri, 1 Nov 2013 20:14:09 +0000

On Fri, 01 Nov 2013 09:30:22 -0700
Russ Allbery <rra@debian.org> wrote:

> I don't personally consider this a major issue

It's probably not something that cannot be worked around in some way,
as the upstart position statement asserts (which by the way I *have*
read).

However, IMHO systemd's cgroups solution makes a whole lot more sense
from a technical PoV, and also fixes a couple of other problems which
SysV init is notorious for.

Apropos of upstart's position statement, it says that
> upstart provides more granular definitions of service readiness
> that are not available in systemd. 

Personally I consider this to be a bug. A daemon either can accept
requests, or it cannot. A file system is either mounted, or it is
not. Anything else is internal fiddling by the init subsystem and
should not be of any interest, or in fact visible (unless you're
debugging daemon startup), to anybody else.

… and another thing, speaking about accepting requests:

One of the interesting side effects of socket activation, as
implemented by systemd, is that one can restart a service (even one
using multiple sockets and dbus and whatnot) without losing a single
request.

AFAIK, upstart cannot do that: its socket activation only passes a
single socket to the daemon, if I interpret the manpage at 
http://manpages.ubuntu.com/manpages/raring/en/man7/socket-event.7.html
correctly.

This is an example of the fundamental difference between upstart's
model, which is based on events, and systemd's, which relies on
service states and dependencies.
IMHO the systemd model makes a lot more sense, from the PoV of a system
administrator. You can easily ask systemd which preconditioon prevents a
daemon from starting up. Asking upstart which event ultimately failed
to fire for (one of?) a daemon's "start on" conditions to be fulfilled
is a more "interestig" problem.

*****

My personal bottom line is that systemd has a whole lot of features
which I am already taking for granted -- I started using systemd as my
primary init system on a wide range of Debian systems since it showed
up in Experimental -- and which other init implementations do not
provide. To be perfectly frank, I'd rather switch distros than stop
using systemd.

IMHO, maintaining "duplicate" init scripts for <whatever we decide
non-Linux Debian systems should standardize on> would consume far less
manpower than re-implementing systemd's journal, and re-implementing a
cgroups controller, and getting whatever we decide on to work with
kdbus in the future, and getting logind and whatnot to run without
systemd, and getting gnome (and maybe others) to not require systemd
as PID 1, … the list goes on.

To be fair, some of this work is going to be necessary anyway, assuming
that Debian continues to treat non-Linux kernels as first-class
citizens. However, the burden of doing it (and to live with the
inevitable bugs) should be carried by those who require it.

-- 
-- Matthias Urlichs

Message #395 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Fri, 1 Nov 2013 21:52:22 -0500

[Message part 1 (text/plain, inline)]

Hi Russ,

On Tue, Oct 29, 2013 at 04:16:04PM -0700, Russ Allbery wrote:

> Therefore, I think it's important for arguments against using systemd to
> somehow engage directly with the questions about functionality.  Either
> there needs to be an argument that the functionality is not important and
> can be done without (which raises questions about how one would build
> GNOME in such an environment), or there needs to be some sort of plan for
> how equivalent functionality to systemd will be provided.

I agree; and the plan from the Upstart side is to ensure that equivalent
functionality remains available, but it's premature to try to flesh this
plan out in any detail while the interfaces themselves are not yet
finalized.

For the TC decision, what kind of information are you looking for about the
plans, beyond "the Ubuntu developers expect to need to address this before
upgrading from systemd logind 204 and will hold at 204 until a correct
solution is known"?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #400 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Steve Langasek <vorlon@debian.org>

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Fri, 01 Nov 2013 20:11:38 -0700

Steve Langasek <vorlon@debian.org> writes:

> For the TC decision, what kind of information are you looking for about
> the plans, beyond "the Ubuntu developers expect to need to address this
> before upgrading from systemd logind 204 and will hold at 204 until a
> correct solution is known"?

I think the right way to put this is that systemd has significant
development resources behind it and is working in fairly close cooperation
with both kernel developers and GNOME developers to make available new
kernel functionality and to provide implementations of various other
interfaces.  Multiple implementations are good, but there's potentially an
ongoing stream of development to keep up with, and (putting aside
arguments about coupling and appropriate ways to integrate that
functionality) I believe there is a general agreement that functionality
is desirable and will be used by other software that Debian wants to
provide.

So, one question is whether anyone outside of Canonical is in a position
to help with the heavy development (as opposed to the occasional patch).
Red Hat is clearly committed to systemd, and there's some convergence
towards it among other RPM-based distributions, so long-term resources for
systemd don't seem to be in doubt.  Canonical is a smaller company, and
does not always have the resources to keep projects for which it is the
sole upstream vibrant and growing, even when it seems strongly committed
to them (c.f. bzr).

If Canonical *is* the sole upstream, the upstream future here is troubling
to me, particularly given Canonical's current strategic direction towards
Unity.  To give a specific example of the sort of thing that I'm worried
about, suppose that GNOME Shell wants a new piece of functionality that
is, on Red Hat, provided via kernel functionality managed by systemd, but
Unity has no need for that functionality.  Is Canonical going to develop
an upstart equivalent in support of GNOME Shell, when it is pushing Unity
over GNOME Shell?

Maybe this example is very artificial; I know it's not clear what piece of
functionality would be required from the init system and surrounding
infrastructure that would be required by GNOME Shell and not Unity.  But I
think it's at least conceivable given different priorities around such
things as multiseat, and in any case it provides a concrete example of the
sort of scenario I'm worried about.

In other words, it's not so much a specific roadmap as it is a roadmap
approach and resource committment.  Debian, by choosing a default init
system, is potentially investing a lot of developer effort on supporting
that platform for packaged daemons, somewhat akin to an organization
choosing a product on which to base a required piece of internal
functionality.  I'm therefore asking the same sort of question that I
would ask of a vendor whose products we were evaluating for my day job:
what guarantees do we have that this product will continue to be developed
and supported going forward?

The situation with free software is a bit different from a vendor, of
course, since Debian could always patch or even pick up development of the
software ourselves, but I think we'd all agree that Debian ending up
committed to a system service family (since that's really what we're
talking about here -- not just the init system itself, but also how the
equivalents, forks, or refactorings of logind, D-Bus, cgroups, udev, and
so forth will be handled) whose pace of development has slowed to the
extent that bzr's has would be a very bad outcome.

At least superficially, that outcome looks more likely to me with upstart
than it does with systemd, so I'm looking for some reassurance for why the
risk of ending up in that situation is low.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #403 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org>

To: Russ Allbery <rra@debian.org>

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Sat, 02 Nov 2013 12:40:19 +0100

Hi,

Russ Allbery <rra@debian.org> writes:
> Steve Langasek <vorlon@debian.org> writes:
>
>> For the TC decision, what kind of information are you looking for about
>> the plans, beyond "the Ubuntu developers expect to need to address this
>> before upgrading from systemd logind 204 and will hold at 204 until a
>> correct solution is known"?
>
[...]
>
> If Canonical *is* the sole upstream, the upstream future here is troubling
> to me, particularly given Canonical's current strategic direction towards
> Unity.  To give a specific example of the sort of thing that I'm worried
> about, suppose that GNOME Shell wants a new piece of functionality that
> is, on Red Hat, provided via kernel functionality managed by systemd, but
> Unity has no need for that functionality.  Is Canonical going to develop
> an upstart equivalent in support of GNOME Shell, when it is pushing Unity
> over GNOME Shell?
>
> Maybe this example is very artificial; I know it's not clear what piece of
> functionality would be required from the init system and surrounding
> infrastructure that would be required by GNOME Shell and not Unity.  But I
> think it's at least conceivable given different priorities around such
> things as multiseat, and in any case it provides a concrete example of the
> sort of scenario I'm worried about.

Thanks for finding a nice wording for this. This is also my main concern
in the init systemd discussions: upstart might end up playing catch-up,
but stay behind in the end.

In Lennart's Google+ post referenced earlier in the discussion[1] there
was also an example of new functionality in systemd 205+ that I'm not
sure Canonical has a business interest in supporting (namely "all the
nifty stuff that allows Wayland to run nicely without privs is
implemented in the newer logind versions"). As Canonical has decided to
go with Mir instead of Wayland, these features might not get backported
to their logind fork (unless they are also required there, I don't
know).

So having a more concrete roadmap than "we might just stay at logind 204
forever" from the UpstarT proponents seems very important to me.

  [1] <https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf>

Ansgar

Message #408 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 727708@bugs.debian.org, Tollef Fog Heen <tfheen@debian.org>, Michael Biebl <biebl@debian.org>

Subject: Re: Bug#727708: init system question before the technical committee

Date: Sat, 02 Nov 2013 12:50:52 +0100

Hi Ian,

Le jeudi 31 octobre 2013 à 15:01 +0000, Ian Jackson a écrit : 
> Perhaps it would be good if the camp leader(s) for each camp would
> reply with a summary of:
>   - the status of their own main arguments: are you mostly done,
>      or do you expect to add more substantial points
>   - the status of their rebuttals: subject of course, to any future
>      changes by the other camps, how close are you to having what
>      you consider a good answer to the other camps' points ?

With some help from the other systemd proponents, I have added today
what I consider the final touch for the systemd statement page. It is
now mostly finished, including the rebuttals, and should only need new
updates for spelling mistakes or minor inaccuracies.

Cheers,
-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-

Message #413 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>

To: Russ Allbery <rra@debian.org>

Cc: 727708@bugs.debian.org, Steve Langasek <vorlon@debian.org>

Subject: Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Mon, 04 Nov 2013 11:23:26 +0100

[Message part 1 (text/plain, inline)]

On 02/11/13 04:11, Russ Allbery wrote:
> I think the right way to put this is that systemd has significant
> development resources behind it and is working in fairly close cooperation
> with both kernel developers and GNOME developers to make available new
> kernel functionality and to provide implementations of various other
> interfaces.  Multiple implementations are good, but there's potentially an
> ongoing stream of development to keep up with, and (putting aside
> arguments about coupling and appropriate ways to integrate that
> functionality) I believe there is a general agreement that functionality
> is desirable and will be used by other software that Debian wants to
> provide.
> 
> So, one question is whether anyone outside of Canonical is in a position
> to help with the heavy development (as opposed to the occasional patch).
> Red Hat is clearly committed to systemd, and there's some convergence
> towards it among other RPM-based distributions, so long-term resources for
> systemd don't seem to be in doubt.  Canonical is a smaller company, and
> does not always have the resources to keep projects for which it is the
> sole upstream vibrant and growing, even when it seems strongly committed
> to them (c.f. bzr).

Regarding the development force behind each project, I find the following
comparison at Ohloh very illustrative

https://www.ohloh.net/p/compare?project_0=openrc&project_1=upstart&project_2=systemd

[signature.asc (application/pgp-signature, attachment)]

Message #418 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Carlos Alberto Lopez Perez <clopez@igalia.com>

Cc: 727708@bugs.debian.org, Steve Langasek <vorlon@debian.org>

Subject: Re: Bug#727708: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Mon, 04 Nov 2013 09:19:40 -0800

Carlos Alberto Lopez Perez <clopez@igalia.com> writes:

> Regarding the development force behind each project, I find the following
> comparison at Ohloh very illustrative

> https://www.ohloh.net/p/compare?project_0=openrc&project_1=upstart&project_2=systemd

This isn't really a fair comparison since systemd as a project contains
considerably more subsystems than upstart or OpenRC do.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #423 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Peter Dolding <oiaohm@gmail.com>

To: Russ Allbery <rra@debian.org>

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 5 Nov 2013 13:54:49 +1000

On Fri, Nov 1, 2013 at 2:51 PM, Russ Allbery <rra@debian.org> wrote:
> Peter Dolding <oiaohm@gmail.com> writes:
>
>> The one property about systemd unit files that is extremely good is
>> there are no multi line commands.   Every command is a single line.
>
> Yes, that's exactly what I think is obnoxious.  I prefer the upstart
> syntax, which avoids the temptation to write unreadable one-line shell
> constructs.  (Indeed, several have already been posted in recipes in
> various threads on debian-devel about this.)  You can, of course, be
> disciplined about this when writing systemd helper scripts by always
> exernalizing the shell script into a separate file, but I really like that
> upstart lets me inline trivial shell fragments without worrying about
> that while still keeping them readable.
http://www.freedesktop.org/software/systemd/man/systemd.service.html

Systemd in fact support the exec lines being written many times.

ExecStart= is recommend against being used many due to using XDG
desktop processing by somethings.   But that is something can could be
changed in time.  Personally I think it should be changed.
http://www.freedesktop.org/software/systemd/man/systemd.service.html

ExecStartPre=, ExecStartPost= can be written many times.

ExecStartPre= rm somewhere
ExecStartPre= touch somewhere

That is in fact valid and both will run in order.  From the start of
unit file to end.

In fact lot of cases I see one line entries in systemd and I see bad
form.  Unless one line has like if or for statements its really bad
form inside systemd.

Yes systemd supports ; split statements most cases this should not be
used in most cases.  Its cleaner in the log to see what statement
failed the multi line way.

Really I would like to see some of those unreadable single line
script.    I am a little bit suspect they will be people not
understanding systemd.   So failing to split over many Exec statements
for clear readability.

Even using upstart you don't stop people from doing unreadable shell script.
>
> I personally don't find any of your other arguments persuasive (maybe I'm
> too used to writing portable /bin/sh scripts), but I do see where you're
> coming from.

I have been the the receiving end of too many not portable shell
scripts.  My big problem about not being able to set it is what if
Ubuntu and Debian decide on a different /bin/sh to each other.   No
way to set no way to work around this with current upstart.

Its not like /bin/sh has not changed in the past.
https://wiki.ubuntu.com/DashAsBinSh  Has everyone forgot the screw ups
that happened when bash was swapped for dash with the old sysvinit.
They were workable around under sysvinit by setting the scripts that
required bash to bash.   So means to change the shell is remembering
historic stuff ups.

There is already complaints with upstart with canonical controlling
the upstream.  So we have to be very careful with dependencies.

Basically upstart is lacking one key feature.   If it not fixed it
will come back and bite us.   Really I would like to see this fixed
before debian takes up upstart if debian takes up upstart at all.

Openrc and systemd both can work around the prior issues that have
effected sysvinit in history.

Replacement we have to be able to beat up like sysvinit and still have it work.

SourcePath= option exists in systemd to mark a location of a file that
the current file is generated from.   I don't know openrc or upstart
to say if either of them have this functionality as well.

History tells us what is likely to happen again.   History is what
against taking in upstart in it current form.    Upstart in it current
form cannot get past the same issues sysvinit got around without major
trouble.   It should only be a minor fix to add a means to define
/bin/sh as a different executable per service.

Peter Dolding

Message #428 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Peter Dolding <oiaohm@gmail.com>

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Mon, 04 Nov 2013 20:02:35 -0800

Peter Dolding <oiaohm@gmail.com> writes:

> ExecStartPre=, ExecStartPost= can be written many times.

> ExecStartPre= rm somewhere
> ExecStartPre= touch somewhere

That really doesn't help, because...

> In fact lot of cases I see one line entries in systemd and I see bad
> form.  Unless one line has like if or for statements its really bad
> form inside systemd.

...of this.  If you can't write the scripts with proper block structure,
it's actually better to just externalize them in a separate file rather
than doing something this awful to try to inline them.

I don't think you're going to convince me to like this syntax.  :)  But
it's a minor issue.

> Basically upstart is lacking one key feature.  If it not fixed it will
> come back and bite us.  Really I would like to see this fixed before
> debian takes up upstart if debian takes up upstart at all.

I'm afraid there is little chance you will manage to convince me that this
is a key feature.  I've been writing portable shell scripts for years, and
Debian has been dealing with shell portability issues for years.
Regardless of what we do with the init system, we will still have to deal
with this with maintainer scripts, etc.  I do see why you're concerned,
but I just don't see this as critical compared to other issues under
discussion.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #433 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Nikolaus Rath <Nikolaus@rath.org>

To: 727708@bugs.debian.org

Subject: Problems with upstarts event model

Date: Mon, 04 Nov 2013 19:53:33 -0800

Hi,

I just want to raise one issue that I think has not been adequately
addressed by any of the position statements (it has unfortunately been
deleted from the upstart page and been trimmed down a lot on the systemd
page):

I think an important drawback of upstart is the idea of treating
dependencies as events.

The systemd statement already mentions correctly that upstart turns the
dependency chain “upside down”, because it starts a service as soon as
all its dependencies are ready, instead of starting the dependencies of
a service when the service itself should be started.

This has practical implications as well. When trying to debug why a
service isn't starting, it's simpler to investigate which dependency
couldn't be started than to figure out which event was not emitted for
what reason at some point in the past.


Moreover (and, in my opinion, most importantly), by treating
dependencies as events ("start A if B has started" rather than the
conventional "A requires B"), native upstart jobs can create "event
loops" which can block starting of all services in the loop. Example:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/964207 and
discussion at https://lists.debian.org/debian-devel/2013/05/msg01500.html

As far as I can tell, something like this can not happen with systemd units.


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

Message #438 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Nikolaus Rath <Nikolaus@rath.org>

To: Russ Allbery <rra@debian.org>

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Mon, 04 Nov 2013 20:32:45 -0800

On 10/31/2013 09:51 PM, Russ Allbery wrote:
> You can, of course, be
> disciplined about this when writing systemd helper scripts by always
> exernalizing the shell script into a separate file, but I really like that
> upstart lets me inline trivial shell fragments without worrying about
> that while still keeping them readable.

I can very well imagine that this is how sysv init scripts started out.
"Let's make them shell scripts, it's so convenient to be able to place
that extra bit of initialization code in there..."

In other words: the ability to add extra features to upstart jobs by
"extending" them with shell scripts could eventually end up making them
just as complex as sysv scripts. I am guilty of having written some
rather complicated trickery in upstart shell sections myself, so I know
how tempting it is.

(In my case, I was mostly working around my still insufficient
understanding of the upstart event system to start a job only in some
specific conditions. Just coding the condition and stopping the job in
its pre-start script (in itself a rather weird concept, but it came from
the upstart cookbook) turned out to be quicker and easier, but it
certainly wasn't the proper solution...)


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

Message #443 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 05 Nov 2013 09:59:35 +0100

]] Russ Allbery 

> Peter Dolding <oiaohm@gmail.com> writes:
> 
> > ExecStartPre=, ExecStartPost= can be written many times.
> 
> > ExecStartPre= rm somewhere
> > ExecStartPre= touch somewhere
> 
> That really doesn't help, because...
> 
> > In fact lot of cases I see one line entries in systemd and I see bad
> > form.  Unless one line has like if or for statements its really bad
> > form inside systemd.
> 
> ...of this.  If you can't write the scripts with proper block structure,
> it's actually better to just externalize them in a separate file rather
> than doing something this awful to try to inline them.
> 
> I don't think you're going to convince me to like this syntax.  :)  But
> it's a minor issue.

Disliking the syntax is of course fair enough. :-) In general, there
should be enough declarative knobs that you can twiddle that you don't
need to write shell scripts.  That's the idea, at least.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #448 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@ayous.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 5 Nov 2013 10:05:40 +0100

* Russ Allbery (rra@debian.org) [131104 18:21]:
> Carlos Alberto Lopez Perez <clopez@igalia.com> writes:
> 
> > Regarding the development force behind each project, I find the following
> > comparison at Ohloh very illustrative
> 
> > https://www.ohloh.net/p/compare?project_0=openrc&project_1=upstart&project_2=systemd
> 
> This isn't really a fair comparison since systemd as a project contains
> considerably more subsystems than upstart or OpenRC do.

Actually I think this comparison contains valuable data points.
However, one shouldn't think of it as "more code is always better" -
in fact, I have often made the experience that too much code in
critical systems is a problem by itself. And as you pointed out, it
doesn't show the amount of development force correctly.

However, it shows two things: one is as you said that systemd contains
many more subsystems as the others (whether this is good or not is a
different question), the other is that code documentation seems to be
not as verbose as for upstart or OpenRC (in spite of the remarks I saw
earlier about how much documentation is there).


Andi

Message #453 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Chris Knadle <Chris.Knadle@coredump.us>

To: Andreas Barth <aba@ayous.org>, 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 05 Nov 2013 04:39:26 -0500

On Tuesday, November 05, 2013 10:05:40 Andreas Barth wrote:
[...] 
> However, it shows two things: one is as you said that systemd contains
> many more subsystems as the others (whether this is good or not is a
> different question), the other is that code documentation seems to be
> not as verbose as for upstart or OpenRC (in spite of the remarks I saw
> earlier about how much documentation is there).

On the latter point -- according to Ohloh, in OpenRC [1] and Upstart [2], 
19% of the code is comments, where for SystemD [3] it's 11%.

1: https://www.ohloh.net/p/openrc/factoids#FactoidCommentsAverage
2: https://www.ohloh.net/p/upstart/factoids#FactoidCommentsAverage
3: https://www.ohloh.net/p/systemd/factoids#FactoidCommentsLow

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us

Message #458 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@ayous.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 6 Nov 2013 01:03:06 +0100

* Russ Allbery (rra@debian.org) [131102 04:12]:
> If Canonical *is* the sole upstream, the upstream future here is troubling
> to me, particularly given Canonical's current strategic direction towards
> Unity.  To give a specific example of the sort of thing that I'm worried
> about, suppose that GNOME Shell wants a new piece of functionality that
> is, on Red Hat, provided via kernel functionality managed by systemd, but
> Unity has no need for that functionality.  Is Canonical going to develop
> an upstart equivalent in support of GNOME Shell, when it is pushing Unity
> over GNOME Shell?
> [...]
> In other words, it's not so much a specific roadmap as it is a roadmap
> approach and resource committment.  Debian, by choosing a default init
> system, is potentially investing a lot of developer effort on supporting
> that platform for packaged daemons, somewhat akin to an organization
> choosing a product on which to base a required piece of internal
> functionality.

I would like to ask this question even a bit more general (for all
involved init systems): 

How much would we have "vendor lock-in" by each init system? Means, is
there more software except the pure init system we might need to take
if we switch to that init system. Also, what can we expect for the
future? How much does the roadmap allow for exchanging other services
without changing the init service? And also looking from the other
perspective, if we would change the init service later on, which of
the nearby services would we loose at the same moment as the init
service?

For upstart, this might be the case described above.

For systemd, just one example (which might be as artificial as the
upstart example): there are more services included in the code base,
like IIRC a syslog server. Can we continue to run different services,
or do we de-facto need to switch to systemds implementations of the
services? Would upstream be interested to keep the non-systemds
implementation of the accompying services working?

(Examples for the other init systems are also possible, but I think I
can save the time of writing them down. But I would also be
interessted in answer for those.)




Andi

Message #463 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Andreas Barth <aba@ayous.org>

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Tue, 05 Nov 2013 16:16:22 -0800

Andreas Barth <aba@ayous.org> writes:

> I would like to ask this question even a bit more general (for all
> involved init systems):

> How much would we have "vendor lock-in" by each init system? Means, is
> there more software except the pure init system we might need to take if
> we switch to that init system. Also, what can we expect for the future?
> How much does the roadmap allow for exchanging other services without
> changing the init service? And also looking from the other perspective,
> if we would change the init service later on, which of the nearby
> services would we loose at the same moment as the init service?

I think it's worth noting that there are a couple of angles on this.  One
is the direction that you note, but there's also the inverse direction:
committing to a particular init system may mean that we *can't* run some
other piece of software, at least without additional work on our side that
may constitute a fork.

For example, we're apparently already in that situation with logind.  In
order to run logind with an init system other than systemd, we will need
to fork it (to a greater or lesser extent), possibly in conjunction with
Ubuntu and Gentoo.  It would be good to know if there are, or will be,
other cases like that.

We'll want to look at both sides of that question, and try to understand
how much work like that is potentially on the horizon with the various
choices.

> For systemd, just one example (which might be as artificial as the
> upstart example): there are more services included in the code base,
> like IIRC a syslog server. Can we continue to run different services, or
> do we de-facto need to switch to systemds implementations of the
> services?

Yes -- I think both your question and my question are two sides of the
same coin, and what side we're looking at in any given case is largely
determined by whether there *are* any other implementations of that
particular service.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #468 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@ayous.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 6 Nov 2013 01:44:20 +0100

* Russ Allbery (rra@debian.org) [131106 01:21]:
> We'll want to look at both sides of that question, and try to understand
> how much work like that is potentially on the horizon with the various
> choices.

Yes, and I hope that all potential init systems add appropriate
information to their position page (on both sides of this coin).


Andi

Message #473 received at 727708@bugs.debian.org (full text, mbox, reply):

From: "Thijs Kinkhorst" <thijs@debian.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 6 Nov 2013 08:37:06 +0100

On Wed, November 6, 2013 01:16, Russ Allbery wrote:
> We'll want to look at both sides of that question, and try to understand
> how much work like that is potentially on the horizon with the various
> choices.

Do you? In the past Debian has not shied away from making the choice that
it considers technically (or philosophically) the most sound, not the one
that implies the least amount of work. The choice will probably be made on
just a few high-level factors, such as the chosen approach (dependency vs
event based), best user experience and/or licensing.

Facts are being gathered about the percentage of code comments, but I it
seems unlikely that Debian would reject a solution that it thinks is
architecturally superior because of it having fewer code comments.


Cheers,
Thijs

Message #478 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: "Thijs Kinkhorst" <thijs@debian.org>

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 06 Nov 2013 00:10:49 -0800

"Thijs Kinkhorst" <thijs@debian.org> writes:
> On Wed, November 6, 2013 01:16, Russ Allbery wrote:

>> We'll want to look at both sides of that question, and try to
>> understand how much work like that is potentially on the horizon with
>> the various choices.

> Do you? In the past Debian has not shied away from making the choice
> that it considers technically (or philosophically) the most sound, not
> the one that implies the least amount of work. The choice will probably
> be made on just a few high-level factors, such as the chosen approach
> (dependency vs event based), best user experience and/or licensing.

Well, my choice won't be made on just those few high-level factors, for
whatever that matters.  And I seem to have one.  :)

Technically the most sound and implying the least amount of work are not
two unrelated factors.  Apply reductio ad absurdum: vaporware is not
technicallly sound, regardless of what lofty design principles underlie
it.

We need to be realistic here about what we, as a project, can accomplish.
The ideal init system for Debian is, almost by definition, the one we
write ourselves from scratch to do exactly what we want it to do.  There's
a good reason why no one has proposed that.  We have certain realistic
limitations about what we can and can't do as a project, which in this
space, among other things, require us to adopt an existing project rather
than writing our ideal implementation from scratch.

The same also applies to other subsystems that go into our distribution.
We aren't going to, realistically, write our own new syslog
implementation, or our own new user session manager, or our own udev
implementation, or our own desktop environment, or our own kernel.  We're
going to use existing projects, maintained by other people with other
goals, some with goals that have nothing to do with Debian's goals.  We
need to choose useful, interoperable sets of those projects that can, at
the end of the day, come together into a coherent system for our users.
Since that's why we're all here.

As part of that process, we may well contribute to those projects, perhaps
substantially.  But Debian is not an island to itself, and if we pretend
we are, we won't produce the quality of distribution that we want to
produce.  We're part of a larger ecosystem, and that has quite a bit to do
with the specific decision of how we choose our init system.

> Facts are being gathered about the percentage of code comments, but I it
> seems unlikely that Debian would reject a solution that it thinks is
> architecturally superior because of it having fewer code comments.

That metric is trying to get at something that we do care about, namely is
a particular upstream project going to be excessively buggy (poorly
documented code implies harder to understand code implies people make
mistakes when they change it) and can we understand it well enough to make
whatever integration changes we need to make to it.

Percentage of code comments is a very rough and somewhat dubious metric to
use for getting at that question, but it's getting at something real.
Just like the discussion that we had about syntax is getting at something
real around the UI of the init system that we will expose to our users,
even if the specific question of how one embeds shell commands in the
startup script is not one on which the choice of init system will turn.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #483 received at 727708@bugs.debian.org (full text, mbox, reply):

From: "Thijs Kinkhorst" <thijs@debian.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 6 Nov 2013 12:46:17 +0100

On Wed, November 6, 2013 09:10, Russ Allbery wrote:
> "Thijs Kinkhorst" <thijs@debian.org> writes:
>> On Wed, November 6, 2013 01:16, Russ Allbery wrote:
>
>>> We'll want to look at both sides of that question, and try to
>>> understand how much work like that is potentially on the horizon with
>>> the various choices.
>
>> Do you? In the past Debian has not shied away from making the choice
>> that it considers technically (or philosophically) the most sound, not
>> the one that implies the least amount of work. The choice will probably
>> be made on just a few high-level factors, such as the chosen approach
>> (dependency vs event based), best user experience and/or licensing.
>
> Well, my choice won't be made on just those few high-level factors, for
> whatever that matters.  And I seem to have one.  :)
>
> Technically the most sound and implying the least amount of work are not
> two unrelated factors.  Apply reductio ad absurdum: vaporware is not
> technicallly sound, regardless of what lofty design principles underlie
> it.
>
> We need to be realistic here about what we, as a project, can accomplish.
> The ideal init system for Debian is, almost by definition, the one we
> write ourselves from scratch to do exactly what we want it to do.  There's
> a good reason why no one has proposed that.  We have certain realistic
> limitations about what we can and can't do as a project, which in this
> space, among other things, require us to adopt an existing project rather
> than writing our ideal implementation from scratch.

I doubt that Debian writing something from scratch would not be realistic:
Debian actually has chosen to go the self-implementing route in key
infrastructures the past, for example for the installer or package
managers.

Nonetheless, that's not relevant here. There are several likely candidates
in existence, so the choice will not be to use something existing versus
implementing from scratch; the choice will be between existing projects,
and given that, the amount of work per system may differ but the
difference will not likely be that great that it's unsurmountable, as they
exist, they have active upstreams and they have successfully been used in
other distributions.

> That metric is trying to get at something that we do care about, namely is
> a particular upstream project going to be excessively buggy (poorly
> documented code implies harder to understand code implies people make
> mistakes when they change it) and can we understand it well enough to make
> whatever integration changes we need to make to it.

I do agree that it's nice to have the very best code quality available,
but in the long run, having underdocumented code is annoying and may lead
to bugs, but bugs can be fixed and documentation improved; changing the
basic architecture of the system is unlikely to be fixed. I really believe
we are going to regret it if Debian chooses the architecture it likes less
for the reason that it has more documentation.

Which system has better code documentation is not relevant. The relevant
question is whether a system has adequate documentation, regardless of the
documentation of other systems.

I think I would like it better if the choice process was split in two.
First, for each candidate system assess the supportability in Debian. Code
quality can be a factor here. Can we reasonably run this? (Given that the
two major choices have been used by several other distributions probably
qualifies them, but Debian can make its own assessment here.) Then, from
the shortlist of candidates, choose the 'best' one based on high-level but
fundamental criteria, like architecture, licensing etc.

Currently, it seems these two steps (is it supportable vs what should be
the default) are conflated and a big matrix of facts of the different
systems is built.


Cheers,
Thijs

Message #488 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@ayous.org>

To: Thijs Kinkhorst <thijs@debian.org>, 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Wed, 6 Nov 2013 13:29:21 +0100

* Thijs Kinkhorst (thijs@debian.org) [131106 12:51]:
> Nonetheless, that's not relevant here. There are several likely candidates
> in existence, so the choice will not be to use something existing versus
> implementing from scratch; the choice will be between existing projects,
> and given that, the amount of work per system may differ but the
> difference will not likely be that great that it's unsurmountable, as they
> exist, they have active upstreams and they have successfully been used in
> other distributions.

I'm not sure we are all convinced about that. And the question is not
only "do they have active upstreams", but also "would upstream
(continue to) develop things in a direction that's also useful for
us". Taking an example (and this one is made-up, so please don't use
the flame-key on me), if systemd would start to only work with the
gnome desktop chooser this might be considered inacceptable, and
wouldn't be too helpful for us I'd expect. Same example would work
with upstart and unity. Or whatever else.


> I do agree that it's nice to have the very best code quality available,
> but in the long run, having underdocumented code is annoying and may lead
> to bugs, but bugs can be fixed and documentation improved; changing the
> basic architecture of the system is unlikely to be fixed. I really believe
> we are going to regret it if Debian chooses the architecture it likes less
> for the reason that it has more documentation.

In the end (at least from my perspective) we need to choose on a set
of advantages and disadvantages. There are different sets available
(or at least there is no consensus in Debian at large that only one of
them works).

First of all, we need to check which ones would be working at all. If
we notice that one of them won't allow us to properly release jessie,
I think we don't need to check if that architecture might be a bit
nicer. Also, if we notice that one architecture is unbearable broken,
the same applies. If we however notice that a set might only work if
Debian spends quite some effort, and we also notice that there are
enough people in Debian willing to do the work - well, that returns
this set in the group of sets we could choose from.

Of course it still could happen that after this pre-check we end up
with examples where we say "no, really not because" and we have to
re-evaluate what other optins we have. But also we're not there yet.


Andi

Message #493 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>

To: 727708@bugs.debian.org

Subject: New development in systemd ecosystem: networkd

Date: Thu, 07 Nov 2013 13:40:25 +0000

Hey,

There is new exciting development in the systemd ecosystem, one that can be 
used as an argument by both the proponents of systemd and the proponents of 
‘anything than systemd’. It's not mandatory yet, but it was greeted with 
enthusiasm, and I think it will become mandatory as soon it matures a bit, 
considering that servers are RedHat's priority.

Quoting the author of networkd:

> This daemon listens for and configures network devices tagged with
> 'systemd-networkd'. By default, no devices are tagged so this daemon
> can safely run in parallel with existing network daemons/scripts.

> Networks are configured in /etc/systemd/network/*.network. The first
> .network
> file that matches a given link is applied. The matching logic is similar to
> the one for .link files, but additionally supports matching on interface
> name.
 
> The mid-term aim is to provide an alternative to ad-hoc scripts currently
> used in initrd's and for wired setups that don't change much (e.g., as seen
> on servers/and some embedded systems).

More details in the original thread: 
<http://lists.freedesktop.org/archives/systemd-devel/2013-November/014077.html>

Cheers,
– Mirosław Baran

-- 
    DMSNUTS100A INVALID REPLY. ANSWER YES OR NO

Message #498 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Konstantinos Margaritis <markos@freevec.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Thu, 7 Nov 2013 19:53:08 +0200

[Message part 1 (text/plain, inline)]

Hi TC and people,

Another issue that might or might have not already been answered, that
was triggered from seeing direct comparison metrics. Do we have some
kind of a metric or some even personal experience with regards to which
project has been the most friendly in accepting patches *from* Debian?

I think it's also important, especially if the patches are not really
relevant to the project's direct goals, say, fixes for a specific
Debian port or missing feature that Debian needs and has a patch for,
but upstream does not care about. I'm being generic here, but it's
quite common for Debian to have distro-specific patches in its
packages. Some of them can be upstreamed, but there are cases where
Debian has to carry those patches around forever. So the question is,
which of the init systems has been the "friendliest" to Debian so far,
if anyone has any experience on this matter?

Regards

Konstantinos

[Message part 2 (application/pgp-signature, inline)]

Message #503 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Bdale Garbee <bdale@gag.com>

To: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>, 727708@bugs.debian.org

Subject: Re: Bug#727708: New development in systemd ecosystem: networkd

Date: Thu, 07 Nov 2013 11:38:14 -0700

[Message part 1 (text/plain, inline)]

Miroslaw Baran <miroslaw+c+debbugs@makabra.org> writes:

> Quoting the author of networkd:

If the existence of this code helps reduce the number of ad-hoc scripts
in the world as the author hopes, then it may add some value.  However,
in the Debian context, systemd-networkd seems at first glance to be
purely duplicative? 

Bdale

[Message part 2 (application/pgp-signature, inline)]

Message #508 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Bdale Garbee <bdale@gag.com>

Cc: 727708@bugs.debian.org, Miroslaw Baran <miroslaw+c+debbugs@makabra.org>

Subject: Re: Bug#727708: New development in systemd ecosystem: networkd

Date: Thu, 07 Nov 2013 10:50:22 -0800

Bdale Garbee <bdale@gag.com> writes:
> Miroslaw Baran <miroslaw+c+debbugs@makabra.org> writes:

>> Quoting the author of networkd:

> If the existence of this code helps reduce the number of ad-hoc scripts
> in the world as the author hopes, then it may add some value.  However,
> in the Debian context, systemd-networkd seems at first glance to be
> purely duplicative?

It sounds like it does the same thing as ifupdown for static, simple
networks, but doesn't include the more complex stuff.

It's an interesting option to have available.  I could see possibly using
it on servers that don't care about any of the DHCP or wireless
complexity, just to have simpler code paths.  But I suspect we'd want to
leave it turned off by default in Debian for the forseeable future, at
least as long as we have active ifupdown maintainers who are still
interested in keeping that system working.  The transition to something
else would be annoying, and it's not clear there would be much benefit.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #513 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@ayous.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: Init systems: arguments for the CTTE

Date: Thu, 7 Nov 2013 20:47:28 +0100

* Bdale Garbee (bdale@gag.com) [131028 18:51]:
> Josselin Mouette <joss@debian.org> writes:
> 
> > While it is (and can remain) possible, just like in the
> > NM case, to install it without systemd and lose functionality, I think
> > it is unreasonable to ask for a default GNOME installation without it.
> 
> Thanks for making this clear.

http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/
contains a bit more information on the connection of gnome - logind -
systemd.


Andi

Message #518 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Marko Randjelovic <markoran@eunet.rs>

To: Thorsten Glaser <tg@mirbsd.de>, 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>

Cc: debian-devel@lists.debian.org, Steven Chamberlain <steven@pyro.eu.org>, Steve Langasek <vorlon@debian.org>, Thomas Goirand <zigo@debian.org>, Lucas Nussbaum <leader@debian.org>

Subject: Re: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)

Date: Fri, 8 Nov 2013 14:54:37 +0100

Additional arguments in favor of sysvinit:

* systemd and upstart lead to vendor lock-in; it will be complicated
later to return back or change to third option, as well to change from
first to second option

* I don't have a feeling that configuration can be very simpler than
shell scripts; there are things such as 'events' and such things have
to be properly defined)

* If OpenRC's development continues in good direction, Debian could
switch to OpenRC

* If our shell scripts are a mess, then we should clean up the mess,
not trying to escape it by changing whole init system; more precisely,
we should correct mistakes we made in past, such as not enough
abstraction

* existing software (sysvinit+initscripts) can be enhanced:

(1) add new features to sysvinit; e.g. start-stop-daemon could be
extended, to return only when service is ready, or if timeout exceeds
to return with error status (2) add new software in addition to sysvinit
(3) make init scripts more correct (abstraction)
(4) extend configurability (more options in /etc/default/*)

(3) makes (4) easily possible

If sysvinit is in accord with UNIX philosophy, and as they say it is,
than I don't see why (1) and (2) would not be possible, too, and with
not to much effort. 

* What is alleged to be disadvantages of sysvinit (lack of features),
is not really to blame sysvinit, because it does one thing and do it
right. Other features could be implemented as additional software. On
the other hand, what actually was done was writing new software that
make old software obsolete and that do *many* things, which is not in
accord with UNIX philosophy. 

* More complex software has more bugs, old software is cleaned out of
original bugs, and new software is not. 

* Software that is not well commented is hard to understand and find
bugs

For more details:

http://lists.debian.org/20131108125545.1b43fc64@eunet.rs
http://lists.debian.org/20131108134841.715634cc@eunet.rs
http://lists.debian.org/20131105234316.4407f99b@eunet.rs
http://lists.debian.org/20131106135535.7d0919bb@eunet.rs
http://lists.debian.org/20131103102302.4249321d@eunet.rs

Message #523 received at 727708@bugs.debian.org (full text, mbox, reply):

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

To: Marko Randjelovic <markoran@eunet.rs>

Cc: Thorsten Glaser <tg@mirbsd.de>, 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>, debian-devel@lists.debian.org, Steven Chamberlain <steven@pyro.eu.org>, Steve Langasek <vorlon@debian.org>, Thomas Goirand <zigo@debian.org>, Lucas Nussbaum <leader@debian.org>

Subject: Re: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)

Date: Fri, 08 Nov 2013 16:30:28 +0100

On 11/08/2013 02:54 PM, Marko Randjelovic wrote:
> Additional arguments in favor of sysvinit:
> 
> * systemd and upstart lead to vendor lock-in; it will be complicated
> later to return back or change to third option, as well to change from
> first to second option

Exactly what vendor would we be locked into with systemd?

> * I don't have a feeling that configuration can be very simpler than
> shell scripts; there are things such as 'events' and such things have
> to be properly defined)

A bash script as glue code between the init daemon is simpler than the
simple descriptive XDG format used for systemd's unit files? I don't
think so.

> * If OpenRC's development continues in good direction, Debian could
> switch to OpenRC

The word here is "if". It's not going to happen. OpenRC has fundamental
issues which haven't been resolved for years now:

> https://bugs.gentoo.org/show_bug.cgi?id=391945

I don't think this is a viable alternative to anything. We can't work
with vaporware, we need software that actually works.

> * If our shell scripts are a mess, then we should clean up the mess,
> not trying to escape it by changing whole init system; more precisely,
> we should correct mistakes we made in past, such as not enough
> abstraction

And who is going to do it? Are you?

People constantly stating that systems like OpenRC and sysvinit
are actually viable alternatives if someone improved them without
actually stepping forward themselves leaves me up to the impression
that those people actually don't have interests in pushing sysvinit
or OpenRC but just blocking the adoption of systemd or upstart.

> * existing software (sysvinit+initscripts) can be enhanced:
> 
> (1) add new features to sysvinit; e.g. start-stop-daemon could be
> extended, to return only when service is ready, or if timeout exceeds
> to return with error status (2) add new software in addition to sysvinit
> (3) make init scripts more correct (abstraction)
> (4) extend configurability (more options in /etc/default/*)
> 
> (3) makes (4) easily possible

The X.org developers were thinking to do the same with X.org but
at some point figured out that the sources they are dealing
with were such a mess that it's better to start over altogether and
started Wayland, see:

> http://www.youtube.com/watch?v=RIctzAQOe44

> If sysvinit is in accord with UNIX philosophy, and as they say it is,
> than I don't see why (1) and (2) would not be possible, too, and with
> not to much effort. 

No one cares about the "Unix philosophy" (TM), it's not some super
holy cow we're not allowed to touch. Additionally, original Unix
sucks, it's all the GNU- and Linux-specific extensions that
actually made it usable.

> * What is alleged to be disadvantages of sysvinit (lack of features),
> is not really to blame sysvinit, because it does one thing and do it
> right.

No, sysvinit doesn't even do the one thing it does right. It has been
explained many many times before why that isn't the case.

> * More complex software has more bugs, old software is cleaned out of
> original bugs, and new software is not. 

If that should be a dogma we should always stick to, we should
immediately abandon all efforts to improve software and go back
to Linux 0.01.

> * Software that is not well commented is hard to understand and find
> bugs

Your last statement doesn't hold at all without actually giving a
couple if examples where you think that systemd or upstart are
poorly documented.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Message #528 received at 727708@bugs.debian.org (full text, mbox, reply):

From: "Paul R. Tagliamonte" <paultag@gmail.com>

To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>, 727708@bugs.debian.org

Cc: Marko Randjelovic <markoran@eunet.rs>, Thorsten Glaser <tg@mirbsd.de>, Josselin Mouette <joss@debian.org>, Debian Devel <debian-devel@lists.debian.org>, Steven Chamberlain <steven@pyro.eu.org>, Steve Langasek <vorlon@debian.org>, Thomas Goirand <zigo@debian.org>, Lucas Nussbaum <leader@debian.org>

Subject: Re: Bug#727708: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)

Date: Fri, 8 Nov 2013 10:40:33 -0500

[Message part 1 (text/plain, inline)]

This has now been discussed ad nauseam. Can we please stop posting about
this on -devel and let the tech-ctte work?

Thanks,
  Paul


On Fri, Nov 8, 2013 at 10:30 AM, John Paul Adrian Glaubitz <
glaubitz@physik.fu-berlin.de> wrote:

> On 11/08/2013 02:54 PM, Marko Randjelovic wrote:
> > Additional arguments in favor of sysvinit:
> >
> > * systemd and upstart lead to vendor lock-in; it will be complicated
> > later to return back or change to third option, as well to change from
> > first to second option
>
> Exactly what vendor would we be locked into with systemd?
>
> > * I don't have a feeling that configuration can be very simpler than
> > shell scripts; there are things such as 'events' and such things have
> > to be properly defined)
>
> A bash script as glue code between the init daemon is simpler than the
> simple descriptive XDG format used for systemd's unit files? I don't
> think so.
>
> > * If OpenRC's development continues in good direction, Debian could
> > switch to OpenRC
>
> The word here is "if". It's not going to happen. OpenRC has fundamental
> issues which haven't been resolved for years now:
>
> > https://bugs.gentoo.org/show_bug.cgi?id=391945
>
> I don't think this is a viable alternative to anything. We can't work
> with vaporware, we need software that actually works.
>
> > * If our shell scripts are a mess, then we should clean up the mess,
> > not trying to escape it by changing whole init system; more precisely,
> > we should correct mistakes we made in past, such as not enough
> > abstraction
>
> And who is going to do it? Are you?
>
> People constantly stating that systems like OpenRC and sysvinit
> are actually viable alternatives if someone improved them without
> actually stepping forward themselves leaves me up to the impression
> that those people actually don't have interests in pushing sysvinit
> or OpenRC but just blocking the adoption of systemd or upstart.
>
> > * existing software (sysvinit+initscripts) can be enhanced:
> >
> > (1) add new features to sysvinit; e.g. start-stop-daemon could be
> > extended, to return only when service is ready, or if timeout exceeds
> > to return with error status (2) add new software in addition to sysvinit
> > (3) make init scripts more correct (abstraction)
> > (4) extend configurability (more options in /etc/default/*)
> >
> > (3) makes (4) easily possible
>
> The X.org developers were thinking to do the same with X.org but
> at some point figured out that the sources they are dealing
> with were such a mess that it's better to start over altogether and
> started Wayland, see:
>
> > http://www.youtube.com/watch?v=RIctzAQOe44
>
> > If sysvinit is in accord with UNIX philosophy, and as they say it is,
> > than I don't see why (1) and (2) would not be possible, too, and with
> > not to much effort.
>
> No one cares about the "Unix philosophy" (TM), it's not some super
> holy cow we're not allowed to touch. Additionally, original Unix
> sucks, it's all the GNU- and Linux-specific extensions that
> actually made it usable.
>
> > * What is alleged to be disadvantages of sysvinit (lack of features),
> > is not really to blame sysvinit, because it does one thing and do it
> > right.
>
> No, sysvinit doesn't even do the one thing it does right. It has been
> explained many many times before why that isn't the case.
>
> > * More complex software has more bugs, old software is cleaned out of
> > original bugs, and new software is not.
>
> If that should be a dogma we should always stick to, we should
> immediately abandon all efforts to improve software and go back
> to Linux 0.01.
>
> > * Software that is not well commented is hard to understand and find
> > bugs
>
> Your last statement doesn't hold at all without actually giving a
> couple if examples where you think that systemd or upstart are
> poorly documented.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz@debian.org
> `. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>
> --
> To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> Archive: http://lists.debian.org/527D0394.3010806@physik.fu-berlin.de
>
>


-- 
:wq

[Message part 2 (text/html, inline)]

Message #533 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Marko Randjelovic <markoran@eunet.rs>

To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Cc: 727708@bugs.debian.org

Subject: Re: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)

Date: Fri, 8 Nov 2013 18:41:45 +0100

On Fri, 08 Nov 2013 16:30:28 +0100
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

> On 11/08/2013 02:54 PM, Marko Randjelovic wrote:
> > Additional arguments in favor of sysvinit:
> > 
> > * systemd and upstart lead to vendor lock-in; it will be complicated
> > later to return back or change to third option, as well to change from
> > first to second option
> 
> Exactly what vendor would we be locked into with systemd?

I don't want to accuse anyone, but obviously there is a possibility for
a situation similar to lock-in, merely because of what I said: "it will
be complicated later to return back or change to third option".

Message #538 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 727708@bugs.debian.org, Tollef Fog Heen <tfheen@debian.org>, Michael Biebl <biebl@debian.org>, Marco d'Itri <md@linux.it>, Thomas Goirand <zigo@debian.org>, Steve Langasek <vorlon@debian.org>, Steven Chamberlain <steven@pyro.eu.org>, Patrick Lauer <patrick@gentoo.org>, Alexander Vershilov <qnikst@gentoo.org>, Josselin Mouette <joss@debian.org>

Subject: Re: Bug#727708: init system question before the technical committee

Date: Sun, 10 Nov 2013 10:23:06 -0800

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Ian Jackson writes:

>> So I would appreciate it if you (and by "you" I mean each side of the
>> argument) would make sure that your page represents the best case you
>> can put forward.

> This seems to have come along very well in the past few days.

> We now have five camps with pages with substantial content:

>   https://wiki.debian.org/Debate/initsystem/multiple
>   https://wiki.debian.org/Debate/initsystem/openrc
>   https://wiki.debian.org/Debate/initsystem/systemd
>   https://wiki.debian.org/Debate/initsystem/sysvinit
>   https://wiki.debian.org/Debate/initsystem/upstart

> Obviously people will need some time to further flesh this out and
> particularly to write rebuttals (or incorporate points into their main
> text which amount to rebuttals).

> If you're in one of these camps you'll probably want to subscribe to
> the pages of the others, so you can follow what they're doing and make
> sure to respond appropriately.

> How long do people think finalising this is going to take ?  There are
> some potential problems with setting a hard deadline in advance but
> we're hoping to deal with this matter fairly soon now.

We've now gotten confirmation from the maintainers of the systemd position
statement that they consider their statement basically finished.  I think
those are the only position statement maintainers we've heard from.

What is the current status of the other position statements from the
perspective of their maintainers?  Do people have a feel for when they'll
consider their positions finalized, at least pending Technical Committee
feedback and questions?

> Perhaps it would be good if the camp leader(s) for each camp would
> reply with a summary of:
>   - the status of their own main arguments: are you mostly done,
>      or do you expect to add more substantial points
>   - the status of their rebuttals: subject of course, to any future
>      changes by the other camps, how close are you to having what
>      you consider a good answer to the other camps' points ?

I think this would still be a good idea.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #543 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Peter Dolding <oiaohm@gmail.com>

To: Russ Allbery <rra@debian.org>

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Mon, 11 Nov 2013 09:02:28 +1000

On Tue, Nov 5, 2013 at 2:02 PM, Russ Allbery <rra@debian.org> wrote:
> Peter Dolding <oiaohm@gmail.com> writes:
>
>> ExecStartPre=, ExecStartPost= can be written many times.
>
>> ExecStartPre= rm somewhere
>> ExecStartPre= touch somewhere
>
> That really doesn't help, because...
>
>> In fact lot of cases I see one line entries in systemd and I see bad
>> form.  Unless one line has like if or for statements its really bad
>> form inside systemd.
>
> ...of this.  If you can't write the scripts with proper block structure,
> it's actually better to just externalize them in a separate file rather
> than doing something this awful to try to inline them.
>
> I don't think you're going to convince me to like this syntax.  :)  But
> it's a minor issue.

The multi line option in systemd has other uses when debuging.
>
>> Basically upstart is lacking one key feature.  If it not fixed it will
>> come back and bite us.  Really I would like to see this fixed before
>> debian takes up upstart if debian takes up upstart at all.
>
> I'm afraid there is little chance you will manage to convince me that this
> is a key feature.  I've been writing portable shell scripts for years, and
> Debian has been dealing with shell portability issues for years.
> Regardless of what we do with the init system, we will still have to deal
> with this with maintainer scripts, etc.  I do see why you're concerned,
> but I just don't see this as critical compared to other issues under
> discussion.
>
Russ I take it from this point of view.  If we cannot get a minor key
feature for future compatibly taken upstream.  Will means the upstart
maintainer ship has to be classed as proven hostile.   This is in fact
a good test to see what init systems Debian can work with to see if
debian can get minor alterations upstream.  At this point upstart
maintainer-ship is suspected of being possibly hostile.   Its about
time we find out if they are.

As you say we have to deal with maintainers scripts.   We also have to
deal with third party items at times.   Basically upstart is tieing
one of my hands behind my back to deal with bad upstart files.   The
worst risk is ubuntu and debian using a different /bin/sh and having
different portability requirements and I am for some reason forced to
use a ubuntu .deb package for something.  Remember the case of steam
binaries.   History tells us that your idea we can write script
portable is a foolish idea.  Just because you can not everyone else
can.  Like if I have altered a script from some third party they can
blame my alteration.  Yes there is a reason why you must be able to
just change the shell.

This is not exactly a minor issue.   The lack of means to set shell
effects future possibilities of importing binaries built only for
Ubuntu and other distributions using upstart.

Also upstart means writing a more complex auditing tool.  Vastly more
complex.   Systemd single line system is really simple to write a
script to go through and check everything starting exec after the =
for ;  so finding where any maintainer gets the idea of in-lining
foolishly. So is fairly simple to automated a debian test to badly
designed systemd unit files.   Yes the external shell script files
will audit with debians existing tools without modifications.

Peter Dolding

Message #548 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Russ Allbery <rra@debian.org>

Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, Tollef Fog Heen <tfheen@debian.org>, Michael Biebl <biebl@debian.org>, Marco d'Itri <md@linux.it>, Thomas Goirand <zigo@debian.org>, Steven Chamberlain <steven@pyro.eu.org>, Patrick Lauer <patrick@gentoo.org>, Alexander Vershilov <qnikst@gentoo.org>, Josselin Mouette <joss@debian.org>

Subject: Re: Bug#727708: init system question before the technical committee

Date: Tue, 12 Nov 2013 16:04:54 -0800

[Message part 1 (text/plain, inline)]

Hi Russ,

On Sun, Nov 10, 2013 at 10:23:06AM -0800, Russ Allbery wrote:
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > Ian Jackson writes:

> >> So I would appreciate it if you (and by "you" I mean each side of the
> >> argument) would make sure that your page represents the best case you
> >> can put forward.

> > This seems to have come along very well in the past few days.

> > We now have five camps with pages with substantial content:

> >   https://wiki.debian.org/Debate/initsystem/multiple
> >   https://wiki.debian.org/Debate/initsystem/openrc
> >   https://wiki.debian.org/Debate/initsystem/systemd
> >   https://wiki.debian.org/Debate/initsystem/sysvinit
> >   https://wiki.debian.org/Debate/initsystem/upstart

> > Obviously people will need some time to further flesh this out and
> > particularly to write rebuttals (or incorporate points into their main
> > text which amount to rebuttals).

> > If you're in one of these camps you'll probably want to subscribe to
> > the pages of the others, so you can follow what they're doing and make
> > sure to respond appropriately.

> > How long do people think finalising this is going to take ?  There are
> > some potential problems with setting a hard deadline in advance but
> > we're hoping to deal with this matter fairly soon now.

> We've now gotten confirmation from the maintainers of the systemd position
> statement that they consider their statement basically finished.  I think
> those are the only position statement maintainers we've heard from.

> What is the current status of the other position statements from the
> perspective of their maintainers?  Do people have a feel for when they'll
> consider their positions finalized, at least pending Technical Committee
> feedback and questions?

> > Perhaps it would be good if the camp leader(s) for each camp would
> > reply with a summary of:
> >   - the status of their own main arguments: are you mostly done,
> >      or do you expect to add more substantial points
> >   - the status of their rebuttals: subject of course, to any future
> >      changes by the other camps, how close are you to having what
> >      you consider a good answer to the other camps' points ?

> I think this would still be a good idea.

At this point I'm satisfied with
<https://wiki.debian.org/Debate/initsystem/upstart>, at least as a starting
point for further discussion with the TC.  I'm sure the systemd folks and I
could go back and forth interminably polishing our rhetoric, but I'd rather
turn our attention to actual questions that the other members of the TC find
relevant. ;)

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #553 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: Russ Allbery <rra@debian.org>

Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, Tollef Fog Heen <tfheen@debian.org>, Michael Biebl <biebl@debian.org>, Marco d'Itri <md@linux.it>, Thomas Goirand <zigo@debian.org>, Steve Langasek <vorlon@debian.org>, Patrick Lauer <patrick@gentoo.org>, Alexander Vershilov <qnikst@gentoo.org>, Josselin Mouette <joss@debian.org>

Subject: Re: Bug#727708: init system question before the technical committee

Date: Thu, 21 Nov 2013 20:56:31 +0000

[Message part 1 (text/plain, inline)]

Hi,

On 10/11/13 18:23, Russ Allbery wrote:
> What is the current status of the other position statements from the
> perspective of their maintainers?  Do people have a feel for when they'll
> consider their positions finalized, at least pending Technical Committee
> feedback and questions?

Sorry to be so late with this.  I've made some small, final changes to
this position statement and I'd like to call it 'complete':
https://wiki.debian.org/Debate/initsystem/multiple

I don't really feel that any "contra $initsystem" sections or rebuttals
are needed on this page and it reads nicer this way.  And I'm too tired
to argue this much more;  the debate has already taken far more energy
than I would like.

Thanks,
Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

[signature.asc (application/pgp-signature, attachment)]

Message #558 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: 727708@bugs.debian.org

Cc: Patrick Lauer <patrick@gentoo.org>

Subject: Re: Bug#727708: init system question before the technical committee

Date: Wed, 27 Nov 2013 14:07:05 +0800

On 11/22/2013 04:56 AM, Steven Chamberlain wrote:
> Hi,
> 
> On 10/11/13 18:23, Russ Allbery wrote:
>> What is the current status of the other position statements from the
>> perspective of their maintainers?  Do people have a feel for when they'll
>> consider their positions finalized, at least pending Technical Committee
>> feedback and questions?
> 
> Sorry to be so late with this.  I've made some small, final changes to
> this position statement and I'd like to call it 'complete':
> https://wiki.debian.org/Debate/initsystem/multiple
> 
> I don't really feel that any "contra $initsystem" sections or rebuttals
> are needed on this page and it reads nicer this way.  And I'm too tired
> to argue this much more;  the debate has already taken far more energy
> than I would like.
> 
> Thanks,
> Regards,

Hi,

I have the go-ahead from OpenRC upstream (eg: Patrick Lauer) so please
consider the OpenRC page as finalized as well.

Cheers,

Thomas Goirand (zigo)

P.S: Sorry for the delay. As I wrote previously, I had personal and
professional events which delayed this task.

Message #563 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Marko Randjelovic <markoran@eunet.rs>

To: debian-devel@lists.debian.org

Cc: 727708@bugs.debian.org, StevenChamberlain <steven@pyro.eu.org>

Subject: Re: sysvinit: moving the contents out of the Essential: yes package?

Date: Wed, 27 Nov 2013 12:49:39 +0100

On Tue, 26 Nov 2013 18:42:43 +0800
Thomas Goirand <zigo@debian.org> wrote:

> With the above, it's easy to switch from one to the other. Well, that is
> before the mess with the version-depends on sysv-rc introduced by the
> debhelper thing for upstart, which messed-up a few things... I hope many
> packages have been rebuilt with the new debhelper version since that has
> been corrected, especially the essential ones (like ifupdown and the
> others (I can't remember)).

Then I don't understand why on 'multiple' page they say sysvinit+openrc
is infeasible.
	
-- 
https://en.wikipedia.org/wiki/Little_Red_Riding_Hood

my homepage: http://mr.flossdaily.org

Message #568 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: Russ Allbery <rra@debian.org>

Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, Tollef Fog Heen <tfheen@debian.org>, Michael Biebl <biebl@debian.org>, Marco d'Itri <md@linux.it>, Thomas Goirand <zigo@debian.org>, Steve Langasek <vorlon@debian.org>, Patrick Lauer <patrick@gentoo.org>, Alexander Vershilov <qnikst@gentoo.org>, Josselin Mouette <joss@debian.org>

Subject: Re: Bug#727708: init system question before the technical committee

Date: Wed, 27 Nov 2013 19:50:54 +0000

[Message part 1 (text/plain, inline)]

The sysvinit page doesn't have a specific maintainer/advocate.  It is a
collection of opinions from discussion on debian-devel@ and elsewhere.
Other camps have already responded to parts they don't agree with.

Unless any volunteers want to make last-minute small changes, it can
probably be taken as 'complete' as soon the tech-ctte is ready to move
forward with this.  I think maintainers of all the other proposals have
said they are ready now.

Thanks,
Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

[signature.asc (application/pgp-signature, attachment)]

Message #573 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Marko Randjelovic <markoran@eunet.rs>

To: Steven Chamberlain <steven@pyro.eu.org>

Cc: Russ Allbery <rra@debian.org>, Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, Tollef Fog Heen <tfheen@debian.org>, Michael Biebl <biebl@debian.org>, "Marco d'Itri" <md@linux.it>, Thomas Goirand <zigo@debian.org>, Steve Langasek <vorlon@debian.org>, Patrick Lauer <patrick@gentoo.org>, Alexander Vershilov <qnikst@gentoo.org>, Josselin Mouette <joss@debian.org>

Subject: Re: Bug#727708: init system question before the technical committee

Date: Thu, 28 Nov 2013 14:35:21 +0100

[Message part 1 (text/plain, inline)]

On Wed, 27 Nov 2013 19:50:54 +0000
Steven Chamberlain <steven@pyro.eu.org> wrote:

> The sysvinit page doesn't have a specific maintainer/advocate.  It is a
> collection of opinions from discussion on debian-devel@ and elsewhere.
> Other camps have already responded to parts they don't agree with.
> 
> Unless any volunteers want to make last-minute small changes, it can
> probably be taken as 'complete' as soon the tech-ctte is ready to move
> forward with this.  I think maintainers of all the other proposals have
> said they are ready now.
> 
> Thanks,
> Regards,

There were elements in form of conversation, and I have made some
changes, but didn't want to erase what other people wrote, so now there
more elements in form of conversation. Should they be merged (calculate resultant)?

[signature.asc (application/pgp-signature, attachment)]

Message #578 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Thu, 28 Nov 2013 12:49:26 +0000

[Message part 1 (text/plain, inline)]

A friend of mine mentioned to me in the pub that he had seem alarming
reports of systemd security bugs.  Naturally I asked for more
information and he promised me an email with some references.

So, here's what Andrew sent me.  Thanks to Andrew for doing this
legwork.

I'll reply substantively in a moment.

[Message part 2 (message/rfc822, inline)]

From: Andrew Kanaber <akanaber@chiark.greenend.org.uk>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Subject: Systemd bugs

Date: Wed, 27 Nov 2013 20:55:53 +0000

Hi Ian,

Here's the email about systemd security holes that I kept forgetting to send
you. I hope it's (still) useful.

The debian-devel post I was thinking of is <441543.92540.bm@smtp118.mail.ir2.yahoo.com>
but it actually only mentions three vulnerabilities, there's a more complete
list of the ones that have affected Debian at
 https://security-tracker.debian.org/tracker/source-package/systemd

Here's a short summary along with the redhat bug numbers (since the redhat BTS
seems to be the place to go for systemd information)

CVE		summary					Debian BTS	Redhat
2012-0871	systemd-logind insecure file creation	?		795853 
2012-1101	DoS from systemctl status		662029		799902
2012-1174	TOCTOU deletion race in systemd-logind	664364		803358
2013-4327	insecure use of polkit			723713		1006680
2013-4391	systemd journald integer overflow	725357		859051
2013-4392	TOCTOU race updating file perms		725357		859060
2013-4393	systemd journald DoS			725357		859104
2013-4394	improper sanitization of XKB layouts	725357		862324

I think the "really bad one to do with remote connection" the guy on
debian-devel was thinking of is CVE-2013-4391 which mentions possible
arbitrary code execution from a "specially crafted packet" but I'm not sure
under what conditions it would be triggerable over IP, I guess you might have
had to set up your system as a remote journald server.

The bug I mentioned one where bad data in its binary log files causes journald
to go mad and eventially fill up /var with junk is
https://bugzilla.redhat.com/show_bug.cgi?id=974132
and is apparently still not fixed.

Generally the RedHat BTS at
https://bugzilla.redhat.com/buglist.cgi?quicksearch=Component:systemd
and 
https://bugzilla.redhat.com/buglist.cgi?quicksearch=Component:systemd+Status:CLOSED
make alarming reading

Hope this helps,

Andrew

Message #583 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Thu, 28 Nov 2013 13:43:27 +0000

Andrew Kanaber <akanaber@chiark.greenend.org.uk>:
> The debian-devel post I was thinking of is <441543.92540.bm@smtp118.mail.ir2.yahoo.com>
> but it actually only mentions three vulnerabilities, there's a more complete
> list of the ones that have affected Debian at
>  https://security-tracker.debian.org/tracker/source-package/systemd

In summary, I agree with Andrew Kanaber's view that the security and
bug history of systemd is worrying.


> Here's a short summary along with the redhat bug numbers (since the
> redhat BTS seems to be the place to go for systemd information)
> 
> CVE		summary					Debian BTS	Redhat
> 2012-0871	systemd-logind insecure file creation	?		795853 
> 2012-1101	DoS from systemctl status		662029		799902
> 2012-1174	TOCTOU deletion race in systemd-logind	664364		803358
> 2013-4327	insecure use of polkit			723713		1006680
> 2013-4391	systemd journald integer overflow	725357		859051
> 2013-4392	TOCTOU race updating file perms		725357		859060
> 2013-4393	systemd journald DoS			725357		859104
> 2013-4394	improper sanitization of XKB layouts	725357		862324

It isn't always 100% clear to me from reading these which of them
apply to systemd's init replacement.  But reading the systemd debate
page makes it clear that the other components in the systemd upstream
package are seen by systemd proponents as part of their offering, and
indeed reasons to pick systemd.  Integration between the different
parts of the systemd package is touted as an advantage.  For example,
journald is mentioned in the 2nd bullet point under Functionality.  So
I think it it is sensible to look at security or other significant
bugs, even in those other systemd components.

Furthermore, I think it is fair to look at bugs in non-pid-1 parts of
the systemd codebase when assessing the likely code quality of the pid
1 parts.

I should say that it is hard to write code with no security bugs at
all.  But I think our benchmark for security bugs in our init system
ought to be "very few", particularly if we are making a specific
implementation effectively mandatory.  And I don't think I would like
to accept justifications (for a large bug count) along the lines of
"but systemd does so much more"; I think the security bugs that come
with a large codebase, or having more functionality exposed to
ordinary users, are a direct and very relevant downside to such a
large codebase or large attack surface.


I went and looked at the security bugs Andrew lists:

There are a couple of filesystem races (CVE-2012-1174, CVE-2013-4392)
which I think a concurrent init system author ought really to be
competent to avoid.  (And the system should be designed, so far as
possible, to reduce the opportunity for such races.)

The "systemctl status" resource usage DoS (CVE-2012-1101) is an
understandable resource leak, given systemd's design.  But for me it
raises this question: why is the system designed in such a way that
the critical pid 1 is required to implement functionality (and
unprivileged-facing interfaces) in which such a resource leak is (a) a
likely programming error and then (b) exposed so as to be exploitable.

AIUI the journald integer overflow (CVE-2013-4391) is a remotely
exploitable bug, if you have configured journald to allow remote
logging.  (I assume this isn't the default configuration but haven't
checked.)

The other journald one (CVE-2013-4393) seems to stem from a poor
design decision: journald expects to be given an fd and then reads
from it.  The authors of this obviously-security-critical code failed
to appreciate the variety of exciting things that can happen to the
recipient of an fd.  I wonder even whether the code change
  http://cgit.freedesktop.org/systemd/systemd/commit/?id=1dfa7e79a60de680086b1d93fcc3629b463f58bd
which is supposed to fix the bug is sufficient.  Even if it does it
certainly isn't pretty.  But also it is concerning that people who
have decided to make extensive use of advanced features of the Linux
system call interface apparently aren't aware of important and
hopefully well-known dangers in facilities such as cross-trust-domain
fd passing.

The XKB one (CVE-2013-4394) is concerning too.  I can't quite tell
exactly in what configurations you would be vulnerable, but the bug
itself is not reassuring as regards the authors' additude to
cross-trust-boundary data processing.  It looks like there's a bunch
of filenames which are taken from the untrusted side and just
textually stuffed into the X server configuration.  Even after the
change which is supposed to fix it,
  http://cgit.freedesktop.org/systemd/systemd/commit/?id=0b507b17a760b21e33fc52ff377db6aa5086c6800
it looks like the system might still accept editor backup,
auto-save files, and the like - the filename patterns which are
accepted seem far too generous.  I wonder if the authors know whether
whether they are exposing the X server to malicious XKB data.


On to non-security bugs:

Andrew again:
> The bug I mentioned one where bad data in its binary log files causes journald
> to go mad and eventially fill up /var with junk is
> https://bugzilla.redhat.com/show_bug.cgi?id=974132
> and is apparently still not fixed.

I read this and some of the links from it.  This is indeed concerning.
Mostly my reaction is "why on earth is this all so complicated?"


> Generally the RedHat BTS at
> https://bugzilla.redhat.com/buglist.cgi?quicksearch=Component:systemd
> and 
> https://bugzilla.redhat.com/buglist.cgi?quicksearch=Component:systemd+Status:CLOSED
> make alarming reading

I agree with this sentiment.  I just looked at a few of these.
Here are a couple of exciting snippets:

https://bugzilla.redhat.com/show_bug.cgi?id=693605#c1

  systemd invents ENOEXEC, resulting in a genuine error due to cycles
  in the dependency graph being reported as "Exec format error" (!)
  In April 2011 a commenter suggests using EINVAL instead but the
  bug unaccountably remains open.

https://bugzilla.redhat.com/show_bug.cgi?id=708537

  Problems with runlevel emulation doing mad things.  It isn't clear
  to me whether this bug is a symptom of a fundamental problem with
  systemd's state-based dependency model, or whether it's simply a
  missing feature or perhaps even wrong default configuration.  But
  the bug has been open for some time.


Ian.

Message #588 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Uoti Urpala <uoti.urpala@pp1.inet.fi>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Thu, 28 Nov 2013 22:00:23 +0200

Ian Jackson wrote:
> It isn't always 100% clear to me from reading these which of them
> apply to systemd's init replacement.  But reading the systemd debate
> page makes it clear that the other components in the systemd upstream
> package are seen by systemd proponents as part of their offering, and
> indeed reasons to pick systemd.

Yes, the other tools that systemd provides and enables are part of its
usefulness, so it is appropriate to look into their quality.


> I should say that it is hard to write code with no security bugs at
> all.  But I think our benchmark for security bugs in our init system
> ought to be "very few", particularly if we are making a specific
> implementation effectively mandatory.  And I don't think I would like
> to accept justifications (for a large bug count) along the lines of
> "but systemd does so much more"; I think the security bugs that come
> with a large codebase, or having more functionality exposed to
> ordinary users, are a direct and very relevant downside to such a
> large codebase or large attack surface.

But this, I think, is completely wrong. You shouldn't count bugs from
other tools included with systemd against its core init functionality or
vice versa. If for example systemd and coreutils came from the same
source package, that should be "allowed" as many bugs as the current two
separate source packages, not less.

Most of the separate functionality is optional. It's likely that Debian
would want to use it, but then Debian would want that functionality with
other init systems too (or miss it). The most appropriate comparison is
whether it's possible to have similar functionality with less bugs
(whether provided with init system or completely independently). As far
as I can see, for most functionality there are no such alternatives.

At least Upstart, and likely other alternatives to systemd also, would
still use forked versions of at least logind and possibly other tools
originating from systemd. Such forks are worse for security than using
the original systemd one. Thus the fact that logind is developed with
systemd should count in favor of systemd, not against it.

Also, systemd is the system under the most intense scrutiny for security
and other issues, so it's not easy to compare bug counts with
alternatives - alternatives likely have a significantly larger portion
of issues undetected.


> Here are a couple of exciting snippets:

> https://bugzilla.redhat.com/show_bug.cgi?id=708537
> 
>   Problems with runlevel emulation doing mad things.  It isn't clear
>   to me whether this bug is a symptom of a fundamental problem with
>   systemd's state-based dependency model, or whether it's simply a

I think it's completely obvious that there is no "fundamental problem".
I wonder what could make you consider it a possible symptom of one.

>   missing feature or perhaps even wrong default configuration.  But
>   the bug has been open for some time.

My guess is that most people do not consider that "exciting" or really
care - thinking of system states in terms of "runlevels" is mostly
obsolete, and the flaws do not bother many people in the cases where
backwards compatibility is still needed.

Message #593 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Michael Stapelberg <stapelberg@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, <727708@bugs.debian.org>

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Thu, 28 Nov 2013 23:15:09 +0100

Hi Ian,

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
>> CVE		summary					Debian BTS	Redhat
>> 2012-0871	systemd-logind insecure file creation	?		795853 
>> 2012-1101	DoS from systemctl status		662029		799902
>> 2012-1174	TOCTOU deletion race in systemd-logind	664364		803358
>> 2013-4327	insecure use of polkit			723713		1006680
>> 2013-4391	systemd journald integer overflow	725357		859051
>> 2013-4392	TOCTOU race updating file perms		725357		859060
>> 2013-4393	systemd journald DoS			725357		859104
>> 2013-4394	improper sanitization of XKB layouts	725357		862324
>
> It isn't always 100% clear to me from reading these which of them
> apply to systemd's init replacement.  But reading the systemd debate
2012-1101 does, I think 2013-4327 and 2013-4392 might, all the others do
not affect the init part of src:systemd.

> Furthermore, I think it is fair to look at bugs in non-pid-1 parts of
> the systemd codebase when assessing the likely code quality of the pid
> 1 parts.
I don’t really agree. The code quality of other parts of the systemd
ecosystem sure are related and probably provide a good trend of the
overall code quality. However, there are some “subsystems” of systemd,
which are to a big part written by non-core contributors. Take for
example networkd, a minimal network configuration for static
(server-ish) setups, which was largely implemented by Tom Gundersen:
http://cgit.freedesktop.org/systemd/systemd/log/src/network
Or take journald, which also has plenty of contributors:
http://cgit.freedesktop.org/systemd/systemd/log/src/journal?ofs=50
http://cgit.freedesktop.org/systemd/systemd/log/src/journal?ofs=100

One can compare this to the Linux kernel, I think: looking at any
subsystem will give you a somewhat useful idea about the overall code
quality, but it’s not fair to say linux’s syscall security sucks just
by looking at the filesystem code.

> I should say that it is hard to write code with no security bugs at
> all.  But I think our benchmark for security bugs in our init system
> ought to be "very few", particularly if we are making a specific
> implementation effectively mandatory.  And I don't think I would like
> to accept justifications (for a large bug count) along the lines of
> "but systemd does so much more"; I think the security bugs that come
> with a large codebase, or having more functionality exposed to
> ordinary users, are a direct and very relevant downside to such a
> large codebase or large attack surface.
They sure are. OTOH, chosing the init system that receives the most
attention in form of development and is adopted by many other
distributions helps us a lot with security issues. They are no longer
just our problem, but other distributions also care about getting them
fixed quickly.

> There are a couple of filesystem races (CVE-2012-1174, CVE-2013-4392)
> which I think a concurrent init system author ought really to be
> competent to avoid.  (And the system should be designed, so far as
> possible, to reduce the opportunity for such races.)
“a concurrent init system author” sounds strange on multiple counts:
systemd was not written by one author. It is also not concurrent (in
fact it is single-threaded and only links to pthreads to call sync
asynchronously on shutdown), but event-based. As for competency, I am
sure that everybody involved has learned their lesson and will avoid
such issues in the future. I am also sure that other init systems have
(had) similar bugs. And if there is no evidence of that yet, maybe
nobody looked really closely yet…? :)

> The "systemctl status" resource usage DoS (CVE-2012-1101) is an
> understandable resource leak, given systemd's design.  But for me it
> raises this question: why is the system designed in such a way that
> the critical pid 1 is required to implement functionality (and
> unprivileged-facing interfaces) in which such a resource leak is (a) a
> likely programming error and then (b) exposed so as to be exploitable.
a) I think “a likely programming error” is an exaggeration. Do you have
   data on how often there were resource leaks in systemd?
b) I am unclear on how exactly this was exploitable, and the bugs lack
   explanation unfortunately.

Furthermore, I think Lennart’s explanation of why arbitrary units must
be able to be created is fair:
https://bugzilla.redhat.com/show_bug.cgi?id=680122#c1

> AIUI the journald integer overflow (CVE-2013-4391) is a remotely
> exploitable bug, if you have configured journald to allow remote
> logging.  (I assume this isn't the default configuration but haven't
> checked.)
journald does not provide remote logging. See
https://lists.fedoraproject.org/pipermail/devel/2013-July/185585.html

> The other journald one (CVE-2013-4393) seems to stem from a poor
> design decision: journald expects to be given an fd and then reads
> from it.  The authors of this obviously-security-critical code failed
> to appreciate the variety of exciting things that can happen to the
> recipient of an fd.  I wonder even whether the code change
>   http://cgit.freedesktop.org/systemd/systemd/commit/?id=1dfa7e79a60de680086b1d93fcc3629b463f58bd
> which is supposed to fix the bug is sufficient.  Even if it does it
> certainly isn't pretty.  But also it is concerning that people who
> have decided to make extensive use of advanced features of the Linux
> system call interface apparently aren't aware of important and
> hopefully well-known dangers in facilities such as cross-trust-domain
> fd passing.
Personally, I don’t know about every little detail in fd passing
either. If I read you correctly, you seem to be saying one needs to be
an expert in a given area before being allowed to write code in it. I
think it works the other way around: by writing code in that area, you
become an expert in it.

The general statement from your side here seems to be (exaggerating a
bit for the sake of discussion): “look, this software has bugs, even
security bugs, so let’s not use it”. While I certainly would not want to
switch to an extremely buggy software myself either, I think we all know
that software is never entirely free of bugs. Expecting an absence of
bugs even before starting to use that software certainly is
unrealistic.

Moreover, consider that whole classes of bugs existed before, spread out
in the various init scripts, which are obsolete thanks to systemd’s
design, these two just being trivial examples off the top of my head:

• improperly sanitized environment, see e.g.
  https://bugzilla.redhat.com/show_bug.cgi?id=990321

• runaway scripts (e.g. cgi-bin) that spawn children and escape the main
  daemon (e.g. apache2) being stopped.

Instead of focusing on the actual security issues, what I’d much rather
look at is the process with which such bugs are fixed. I.e. are security
problems acknowledged as such, are they fixed clearly and in a timely
manner? Are there enough eyes looking at the project to uncover, report
and collaborate in fixing the issues?

Also, and I think that should go without saying, if this branch of the
discussion is considered as reasoning against systemd in the decision
process, I’d like to see similar data on the other init systems :).

Thanks.

-- 
Best regards,
Michael

Message #598 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Michael Stapelberg <stapelberg@debian.org>, 727708@bugs.debian.org

Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Thu, 28 Nov 2013 20:07:16 -0600

[Message part 1 (text/plain, inline)]

On Thu, Nov 28, 2013 at 11:15:09PM +0100, Michael Stapelberg wrote:
> > I should say that it is hard to write code with no security bugs at
> > all.  But I think our benchmark for security bugs in our init system
> > ought to be "very few", particularly if we are making a specific
> > implementation effectively mandatory.  And I don't think I would like
> > to accept justifications (for a large bug count) along the lines of
> > "but systemd does so much more"; I think the security bugs that come
> > with a large codebase, or having more functionality exposed to
> > ordinary users, are a direct and very relevant downside to such a
> > large codebase or large attack surface.
> They sure are. OTOH, chosing the init system that receives the most
> attention in form of development and is adopted by many other
> distributions helps us a lot with security issues. They are no longer
> just our problem, but other distributions also care about getting them
> fixed quickly.

All distributions "care" about not having security issues in their code, but
that's not the same thing as actually doing the work to audit the code.  In
practice this only happens when dedicated resources are turned on the code
in question, and having more companies using the code does not magically
make that happen.

I don't know that the upstart code has been subjected to any sort of
comprehensive security audit.  I also don't know whether the auditing that's
been done on systemd qualifies as comprehensive.  I *will* assert that
upstart development is aimed at avoiding extraneous features precisely to
reduce the risk of bugs (security or otherwise).

> > There are a couple of filesystem races (CVE-2012-1174, CVE-2013-4392)
> > which I think a concurrent init system author ought really to be
> > competent to avoid.  (And the system should be designed, so far as
> > possible, to reduce the opportunity for such races.)
> “a concurrent init system author” sounds strange on multiple counts:
> systemd was not written by one author. It is also not concurrent (in
> fact it is single-threaded and only links to pthreads to call sync
> asynchronously on shutdown), but event-based. As for competency, I am
> sure that everybody involved has learned their lesson and will avoid
> such issues in the future.

Are the systemd developers novice programmers, that they need to learn to
program securely by trial and error?

The reality is that the kind of security bugs that we're talking about are
very subtle, and even experienced developers are going to make mistakes like
this from time to time, and as one of the arguments advanced for systemd is
that it has a large community of contributors, not all of those contributors
are going to be experienced developers.  A project's security record has at
least as much to do with having a solid design to reduce the attack surface,
as it does with the developers' skill.

> I am also sure that other init systems have (had) similar bugs.  And if
> there is no evidence of that yet, maybe nobody looked really closely yet…? 
> :)

Unless you're offering to do a security audit of upstart, I don't think such
speculation changes anything.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #603 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Michael Stapelberg <stapelberg@debian.org>, 727708@bugs.debian.org, Uoti Urpala <uoti.urpala@pp1.inet.fi>

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question) [and 1 more messages]

Date: Fri, 29 Nov 2013 12:37:23 +0000

Uoti Urpala writes ("Bug#727708: systemd (security) bugs (was: init system question)"):
> [Ian Jackson:]
> > Here are a couple of exciting snippets:
> > https://bugzilla.redhat.com/show_bug.cgi?id=708537
> > 
> >   Problems with runlevel emulation doing mad things.  It isn't clear
> >   to me whether this bug is a symptom of a fundamental problem with
> >   systemd's state-based dependency model, or whether it's simply a
> 
> I think it's completely obvious that there is no "fundamental problem".
> I wonder what could make you consider it a possible symptom of one.
> 
> >   missing feature or perhaps even wrong default configuration.  But
> >   the bug has been open for some time.
> 
> My guess is that most people do not consider that "exciting" or really
> care - thinking of system states in terms of "runlevels" is mostly
> obsolete, and the flaws do not bother many people in the cases where
> backwards compatibility is still needed.

Statements like this are part of what make me think this might be a
fundamental problem.  When a systemd proponent tells me that a
particular use pattern is unimportant or wrongheaded, I tentatively
infer that systemd cannot support it properly.

It seems to me that the difficulties with the runlevel emulation are
likely to affect other similar use patterns too.  The problems don't
seem specific to the nature of runlevels.  Perhaps they are specific
to the way runlevels are emulated by systemd but in that case that
emulation should surely be fixed.


Michael Stapelberg writes ("Bug#727708: systemd (security) bugs (was: init system question)"):
> [Ian Jackson:]
> > There are a couple of filesystem races (CVE-2012-1174, CVE-2013-4392)
> > which I think a concurrent init system author ought really to be
> > competent to avoid.  (And the system should be designed, so far as
> > possible, to reduce the opportunity for such races.)
>
> “a concurrent init system author” sounds strange on multiple counts:
> systemd was not written by one author. It is also not concurrent (in
> fact it is single-threaded and only links to pthreads to call sync
> asynchronously on shutdown), but event-based.

systemd, like upstart, is concurrent in that it does more than one
thing at once.  In particular, it does concurrent startup of
services.

One of the main potential advantages of a new approach to service
management is that it is less racy.  This advantage depends on the
authors of the replacement having thought about the problems in the
right way, and not written racy code.

> As for competency, I am sure that everybody involved has learned
> their lesson and will avoid such issues in the future.

My point was that someone who is writing an init system for concurrent
startup and dynamic service management needs to have a good
understanding of concurrent system design, and in particular of race
hazards.  I wouldn't expect a person or people who had such an
understanding to make many mistakes of the kind seen here.


> > The "systemctl status" resource usage DoS (CVE-2012-1101) is an
> > understandable resource leak, given systemd's design.  But for me it
> > raises this question: why is the system designed in such a way that
> > the critical pid 1 is required to implement functionality (and
> > unprivileged-facing interfaces) in which such a resource leak is (a) a
> > likely programming error and then (b) exposed so as to be exploitable.
>
> a) I think “a likely programming error” is an exaggeration. Do you have
>    data on how often there were resource leaks in systemd?

AIUI from reading the advisories (I haven't read the code) this was a
simple memory leak bug.

> b) I am unclear on how exactly this was exploitable, and the bugs lack
>    explanation unfortunately.

AIUI the exploit works as follows: the attacker runs "systemctl status
<blah>" where <blah> is a random invented unit name.  They then repeat
this millions of times.  Each time systemd allocates memory to record
this phantom unit; this memory is never freed.  Eventually some kind
of resource is exhaused (e.g. RAM, address space, ulimit) and systemd
stops working properly.

> Furthermore, I think Lennart’s explanation of why arbitrary units must
> be able to be created is fair:
> https://bugzilla.redhat.com/show_bug.cgi?id=680122#c1

How was CVE-2012-1101 fixed ?  That bug doesn't show the patch.

[later:]

I went and looked and found this:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=9a46fc3b9014de1bf0ed1f3004a536b08a19ebb3

It looks like the appropriate gc function was simply not called.  As I
thought, an understandable programming error, but one which exists
only because of (perhaps essential) complexity in the code.

More importantly it is one which is exploitable only as a consequence
of the questionable design decision to expose pid 1 to ordinary users.


> > AIUI the journald integer overflow (CVE-2013-4391) is a remotely
> > exploitable bug, if you have configured journald to allow remote
> > logging.  (I assume this isn't the default configuration but haven't
> > checked.)
>
> journald does not provide remote logging. See
> https://lists.fedoraproject.org/pipermail/devel/2013-July/185585.html

Err, so I don't understand then why CVE report this vulnerability as
follows:

| Integer overflow in the valid_user_field function in
| journal/journald-native.c in systemd allows remote attackers to
| cause a denial of service (crash) and possibly execute arbitrary
| code via a large journal data field, which triggers a heap-based
| buffer overflow.

If journald doesn't support remote logging, how is this vulnerability
remotely exploitable ?


> Personally, I don’t know about every little detail in fd passing
> either. If I read you correctly, you seem to be saying one needs to be
> an expert in a given area before being allowed to write code in it. I
> think it works the other way around: by writing code in that area, you
> become an expert in it.

What a startling statement.  This is not some desktop toy we are
talking about; this is critical core system infrastructure.

I would prefer my pid 1 to have been written by experts.  It appears
that you are saying that systemd wasn't and that this isn't important!


> Instead of focusing on the actual security issues, what I’d much rather
> look at is the process with which such bugs are fixed. I.e. are security
> problems acknowledged as such, are they fixed clearly and in a timely
> manner? Are there enough eyes looking at the project to uncover, report
> and collaborate in fixing the issues?

I don't think having a functioning security response process is a
substitute for good system design, and a high initial code quality.

And I don't think that "many eyes" is as helpful as you apparently
think.  Security code review is bloody hard work.


> Also, and I think that should go without saying, if this branch of the
> discussion is considered as reasoning against systemd in the decision
> process, I’d like to see similar data on the other init systems :).

You are of course welcome to go and find that information.


Ian.

Message #608 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Fri, 29 Nov 2013 17:55:39 +0100

Le jeudi 28 novembre 2013 à 13:43 +0000, Ian Jackson a écrit : 
> In summary, I agree with Andrew Kanaber's view that the security and
> bug history of systemd is worrying.

Personally, I find the flow of bugs (including security bugs) for
moderately recent software the sign of a healthy project. A simple look
at a few packages in the BTS will show that packages with lots of
reported bugs are packages with lots of users and features, regardless
of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come
to mind as being full of bugs, including security bugs.

Indeed, systemd has not been written with security in mind. Neither have
sysvinit nor upstart, AFAICT. Yes, it would be better if *all*
developers had a better grasp of secure programming, but on the other
hand, asking the first people to use some advanced kernel interfaces to
understand all their security implications is unfair. Just like we don’t
hold the Mozilla developers responsible for security issues in brand-new
Javascript engines that maybe 10 developers in the world could
understand.

As Michael mentioned, systemd has a broader scope than alternatives.
You’d have to use a system providing similar features as a basis for a
fair comparison, and such a system doesn’t really exist in the Unix
world. If you only take into account the features that are also provided
by upstart or sysvinit/insserv, you won’t find that many of these bugs
apply. Compare that to the number of unfixable bugs in sysvinit due to
broken design. 

Cheers,
-- 
 .''`.        Josselin Mouette
: :' :
`. `'
  `-

Message #613 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Fri, 29 Nov 2013 17:11:52 +0000

Josselin Mouette writes ("Bug#727708: systemd (security) bugs (was: init system question)"):
> Personally, I find the flow of bugs (including security bugs) for
> moderately recent software the sign of a healthy project. A simple look
> at a few packages in the BTS will show that packages with lots of
> reported bugs are packages with lots of users and features, regardless
> of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come
> to mind as being full of bugs, including security bugs.

All of those components are to a greater or lesser extent optional.
What we are being asked is to make use of systemd mandatory.

> Indeed, systemd has not been written with security in mind.

What an alarming comment on a program which has ultimate privilege, is
intended to be universally deployed even in the most demanding
security environment, crosses security boundaries (without, IMO, a
sufficient justification), and is being touted as the single
systemwide manager for security features like cgroups !

> Neither have sysvinit nor upstart, AFAICT.

I will leave the upstart maintainers to comment on this in more
detail, but sysvinit has had remarkably few security bugs for a
program of its vintage.  This is because it has very few, and very
restricted, interfaces to untrusted parts of the system.

>  Just like we don’t hold the Mozilla developers responsible
> for security issues in brand-new Javascript engines that maybe 10
> developers in the world could understand.

The security record of web browsers is indeed atrocious.  It is the
result of a persistent swamp of bad design decisions, hideous
overcomplexity, plain bad code, and lack of attention to mitigation
measures.  Google's efforts in this area are to be applauded, even
though I have serious privacy problems with Google.

It is very alarming that web browsers are being presented as the
security benchmark for our new init system.

Ian.

Message #618 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Fri, 29 Nov 2013 11:35:20 -0600

[Message part 1 (text/plain, inline)]

On Fri, Nov 29, 2013 at 05:55:39PM +0100, Josselin Mouette wrote:
> Indeed, systemd has not been written with security in mind. Neither have
> sysvinit nor upstart, AFAICT.

I wouldn't presume to say whether the systemd authors had security in mind
while writing it.  But I will stand by the overall security design of either
sysvinit or upstart, namely that the user-accessible interfaces are kept as
small as possible to make them as auditable as possible.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #623 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Fri, 29 Nov 2013 19:18:33 +0100

Le vendredi 29 novembre 2013 à 17:11 +0000, Ian Jackson a écrit : 
> Josselin Mouette writes ("Bug#727708: systemd (security) bugs (was: init system question)"):
> > Personally, I find the flow of bugs (including security bugs) for
> > moderately recent software the sign of a healthy project. A simple look
> > at a few packages in the BTS will show that packages with lots of
> > reported bugs are packages with lots of users and features, regardless
> > of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come
> > to mind as being full of bugs, including security bugs.
> 
> All of those components are to a greater or lesser extent optional.

Linux is optional?
X is optional? Not for everyone. (X is a bad example anyway, because,
unlike the rest, it *has* a bad security design.)

> What we are being asked is to make use of systemd mandatory.

It doesn’t mean that all of systemd’s features should be enabled on all
machines. The reason why embedded manufacturers are sponsors for
systemd’s development is that it means less code, and therefore less
bugs (security or not), than alternatives.

> > Indeed, systemd has not been written with security in mind.
> 
> What an alarming comment on a program which has ultimate privilege, is
> intended to be universally deployed even in the most demanding
> security environment, crosses security boundaries (without, IMO, a
> sufficient justification), and is being touted as the single
> systemwide manager for security features like cgroups !

Only an extreme minority of Debian packages have been written with
security in mind. Not all packages can be OpenSSH or Postfix, and we
have to live with that fact, because we need the features in other
packages (starting with a kernel and libc).

> > Neither have sysvinit nor upstart, AFAICT.
> 
> I will leave the upstart maintainers to comment on this in more
> detail, but sysvinit has had remarkably few security bugs for a
> program of its vintage.  This is because it has very few, and very
> restricted, interfaces to untrusted parts of the system.

And of course, there has never been any buggy init script.

Again, your comparison doesn’t make any sense since you don’t compare
similar functionality scopes.

> >  Just like we don’t hold the Mozilla developers responsible
> > for security issues in brand-new Javascript engines that maybe 10
> > developers in the world could understand.
> 
> The security record of web browsers is indeed atrocious.  It is the
> result of a persistent swamp of bad design decisions, hideous
> overcomplexity, plain bad code, and lack of attention to mitigation
> measures.  Google's efforts in this area are to be applauded, even
> though I have serious privacy problems with Google.

I’m afraid you don’t entirely understand why the security record of web
browsers looks atrocious. Because of a swamp of bad decisions *from web
developers and designers*, backed by users, browsers have to cover a
functional scope that far exceeds in complexity any other kind of
software. A typical browser has to include several virtual machines,
graphical/layout toolkits, JIT compilers, advanced cryptographic
software, all of which have to work with heaps of untrusted data. When
taking all of that into account, as much as I hate dealing with them, I
have to admit the security record for several browsers is good, and it’s
because they *are* developed with security in mind.

> It is very alarming that web browsers are being presented as the
> security benchmark for our new init system.

It is quite alarming that a member of the Technical Committee
demonstrates lacks in security knowledge while at the same time using
security bugs as a measure for comparing solutions.


This “security” discussion has nothing to do with the case in point,
though. If you have specific points you want addressed by the systemd
position (like how systemd’s upstream designs user interfaces to avoid
security bugs, or handles security alerts), please state them clearly
and I will do my best to gather information for you and answer them.

-- 
 .''`.        Josselin Mouette
: :' :
`. `'
  `-

Message #628 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@ayous.org>

To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Fri, 29 Nov 2013 19:32:32 +0100

* Josselin Mouette (joss@debian.org) [131129 19:21]:
> It is quite alarming that a member of the Technical Committee
> demonstrates lacks in security knowledge

I would prefer if you could stop doing ad-hominem attacks (independend
on whom - this is not an acceptable behaviour).


Andi

Message #633 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Paul Tagliamonte <paultag@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Fri, 29 Nov 2013 13:58:47 -0500

[Message part 1 (text/plain, inline)]

On Fri, Nov 29, 2013 at 05:11:52PM +0000, Ian Jackson wrote:
> It is very alarming that web browsers are being presented as the
> security benchmark for our new init system.

So, I tend to agree with Joss here - Web browsers is the biggest attack
surface that we have today, bar none. I don't think anyone really
disputes this.

The safety of modern web browsers is (well, minus a qualifier below), frankly,
shockingly good.

The amount of exploits from JS is crazy low for something that's able to
do so much (store data locally, use WebGL / 3D rendering, play audio),
it is shockingly hard to exploit.

When you look at the entire stack (CSS parsers / evaluators, HTML
parsers & evaluators, JS parsers and evaluators), the only disaster
would be stuff like ActiveX. I'm not sure of it's state, since I've
never run a platform that supports it, but I hear it's getting better.

So, yes, browsers are a cespool, but it's one that runs complete garbage
on the internet.

I'd be stunningly happy to see an init system that can handle as much
pure crap as browsers have to put up with :)


More on-topic, I do think that the systemd bugs are more likely because
people are playing with the code, exploring it for holes, and pushing
them, which is healthy. I'm sure if you poked hard enough, most systems
would show such bugs. (as has been already said, really)


Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `-     http://people.debian.org/~paultag

[signature.asc (application/pgp-signature, inline)]

Message #638 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Uoti Urpala <uoti.urpala@pp1.inet.fi>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question) [and 1 more messages]

Date: Fri, 29 Nov 2013 22:09:29 +0200

On Fri, 2013-11-29 at 12:37 +0000, Ian Jackson wrote:
> Uoti Urpala writes ("Bug#727708: systemd (security) bugs (was: init system question)"):
> > My guess is that most people do not consider that "exciting" or really
> > care - thinking of system states in terms of "runlevels" is mostly
> > obsolete, and the flaws do not bother many people in the cases where
> > backwards compatibility is still needed.
> 
> Statements like this are part of what make me think this might be a
> fundamental problem.  When a systemd proponent tells me that a
> particular use pattern is unimportant or wrongheaded, I tentatively
> infer that systemd cannot support it properly.

At least here this logic led you to the wrong conclusion, so you might
want to reconsider it.

> It seems to me that the difficulties with the runlevel emulation are
> likely to affect other similar use patterns too.  The problems don't
> seem specific to the nature of runlevels.  Perhaps they are specific
> to the way runlevels are emulated by systemd but in that case that
> emulation should surely be fixed.

The issue was legacy runlevel changes being simply mapped to "isolate
new_runlevel", which does not have quite the same semantics as sysvinit
runlevel changes (most importantly, it stops everything not in the
new_runlevel target, without limiting to only things that were part of
original runlevel target). There's no reason why the set of services to
stop could not be calculated in a way closer to sysvinit semantics. But
there's little reason to deal with "runlevels" at all when using
systemd, and it seems most people don't. So while the backwards
compatibility support could be improved (probably rather easily), I
think it's clear why this has not been a priority for either developers
or users.


> More importantly it is one which is exploitable only as a consequence
> of the questionable design decision to expose pid 1 to ordinary users.

I think there are good reasons to allow querying status directly. One
sanity check that IMO should be kept in mind for perspective when
considering any "even one DoS issue in PID 1 is a catastrophe" arguments
is that Debian will always require running a kernel, and there have been
lots of DoS or worse issues there. Unless you expect the majority of
Debian users to move to minimal microkernels in the near future, there
is little basis to demand an absolutely minimal init process when the
kernel contains much more code in a more critical role.

The same applies to this:
> and is being touted as the single systemwide manager for security
> features like cgroups !

Parts of the implementation for this are on the kernel side, parts on
the systemd side. I see no reason to think that the systemd side would
be the more problematic one.

Message #643 received at 727708-quiet@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: debian-ctte@lists.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Fri, 29 Nov 2013 20:32:16 +0000

As a system administrator, the idea of a 'kitchen sink' init system
terrifies me.  I would need exceptionally high confidence in its authors
and design principles before allowing it to run as root on my systems
and depend on it to boot even to single user.  I wouldn't even invest
much time enquiring into this, if I knew I could manage with something
simpler having less scope for security/reliability bugs.

OTOH I would be much more forgiving if this were being used for, say,
employees' own desktop machines in a protected corporate IT environment.
 Lots of systemd's features seem particularly convenient for that use
case.  And security is enforced in other ways there (the only people
with access at all, know they risk getting fired for trying to escalate
privileges or DoS).

Adopting systemd may have been much simpler if it had been separate from
and launched by the simple init, starting only the services that have
unit files because they really require its functionality.  If no
installed software on that system needs it, it wouldn't even need to be
installed.

But otherwise I think there are GNU/Linux users who want the choice of
using systemd or being able to use something else.  Preferably without
having to switch a different distro or third-party derivative.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

Message #648 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Fri, 29 Nov 2013 21:32:44 +0000

The original question was which init system[s] are going to be the
default.  But there are still some other things I'm curious about:

1. we already have alternate init systems in the archive;  could it be
some kind of release goal to ensure they are installable?  i.e. make it
possible for them to satisfy the dependencies of essential packages.
(Steve Langasek's metapackage idea in [0] seems to be in the right
direction for accomplishing that, except it wouldn't work for OpenRC or
indeed for keeping the original sysvinit/sysv-rc).

[0]: http://lists.debian.org/debian-devel/2013/11/msg00389.html

2. would exceptions be permitted;  could some packages explicitly depend
on a non-default init system if it's the only one providing
functionality it needs (and still be part of a stable release)?  I'm
thinking that GNOME might (someday, if replacements for logind or other
APIs can't be found) want to do this, if systemd isn't chosen as the
sole default on GNU/Linux.  (It seems similar to a maintainer being able
to restrict packages to Arch: linux-any if they cannot / do not want to
support non-Linux ports).

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

Message #653 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Sat, 30 Nov 2013 09:44:02 +0100

Le vendredi 29 novembre 2013 à 17:55 +0100, Josselin Mouette a écrit : 
> Indeed, systemd has not been written with security in mind.

Obviously, such a subjective judgment of valor does not mean the same to
me as to other developers. It is easy to quote it out of context and say
“oh, look! some systemd advocate said that it is insecure! of course MY
init system of choice is more secure!”, but it is merely a fallacy since
we are not talking about the same thing.

Therefore, I have to retract this statement. 

-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-

Message #658 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Michael Stapelberg <stapelberg@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, Uoti Urpala <uoti.urpala@pp1.inet.fi>

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question) [and 1 more messages]

Date: Sat, 30 Nov 2013 12:00:27 +0100

Hi Ian,

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> My point was that someone who is writing an init system for concurrent
> startup and dynamic service management needs to have a good
> understanding of concurrent system design, and in particular of race
> hazards.  I wouldn't expect a person or people who had such an
> understanding to make many mistakes of the kind seen here.
Neither do I, but there is no evidence for _many_ of these problems.

>> Personally, I don’t know about every little detail in fd passing
>> either. If I read you correctly, you seem to be saying one needs to be
>> an expert in a given area before being allowed to write code in it. I
>> think it works the other way around: by writing code in that area, you
>> become an expert in it.
>
> What a startling statement.  This is not some desktop toy we are
> talking about; this is critical core system infrastructure.
>
> I would prefer my pid 1 to have been written by experts.  It appears
> that you are saying that systemd wasn't and that this isn't important!
To clarify: I do think (most?) systemd authors are experts. I am also
saying that experts can make mistakes, and that having the expectation
that software has 0 bugs is unreasonable.

I also stand by my statement that one cannot be an expert in a subject
area before having experience in that subject area. Sure, one can
prepare, but there is the proverb “practice makes perfect”.

>> Instead of focusing on the actual security issues, what I’d much rather
>> look at is the process with which such bugs are fixed. I.e. are security
>> problems acknowledged as such, are they fixed clearly and in a timely
>> manner? Are there enough eyes looking at the project to uncover, report
>> and collaborate in fixing the issues?
>
> I don't think having a functioning security response process is a
> substitute for good system design, and a high initial code quality.
No argument there. I think having all three of them is better, and
that’s my opinion of systemd, at least of pid 1, which I have looked at
more closely than at the other parts of the larger system.

>> Also, and I think that should go without saying, if this branch of the
>> discussion is considered as reasoning against systemd in the decision
>> process, I’d like to see similar data on the other init systems :).
>
> You are of course welcome to go and find that information.
I may be misunderstanding how this works, but I strongly believe that if
the ctte looks at the security track record of systemd, it MUST also
look at the security track record of the other contenders. I.e., I
consider it unfair to say “we’re not using systemd because it had
security bugs, we’ll chose X instead, but we didn’t look at its security
at all”.

That said, I’d love to help, but I don’t have the time to look at the
security track record of other init systems in detail. Sorry.

-- 
Best regards,
Michael

Message #663 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Moritz Mühlenhoff <jmm@inutil.org>

To: Steve Langasek <vorlon@debian.org>

Cc: Michael Stapelberg <stapelberg@debian.org>, 727708@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Sat, 30 Nov 2013 16:07:17 +0100

On Thu, Nov 28, 2013 at 08:07:16PM -0600, Steve Langasek wrote:
> All distributions "care" about not having security issues in their code, but
> that's not the same thing as actually doing the work to audit the code.  In
> practice this only happens when dedicated resources are turned on the code
> in question, and having more companies using the code does not magically
> make that happen.

[I took care of the systemd DSA people are referring to]

The issue people are talking about were discovered during a review of
the Red Hat Product Security Team (most likely triggered by the inclusion
of systemd into RHEL7).
So in fact having more companies use the code exactly made that magically
happen.

For every complex code base a thorough review will unveil security-related
implementation bugs and the ones found for systemd are not exactly earth-
shattering.

More review and more usage will lead to more bugs being found, we should
rather applaud Red Hat for investing resources and be diligent. After all
Red Hat is the only distro staffing a proactive product security team
(from which everyone is profiting outside of RH as well). I don't consider
the lack of reported security issues for the contenders as a credible 
indication of them being more secure.

FWIW, the main reason I'm personally in favour of adopting systemd is precisely 
security (in terms of sandboxing and restricting services). See
http://0pointer.de/blog/projects/security.html for some pointers.

[EOD from me due to a lack of time, but that needed to be said]

Cheers,
        Moritz

Message #668 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Lars Wirzenius <liw@liw.fi>

To: Moritz Mühlenhoff <jmm@inutil.org>, 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Sat, 30 Nov 2013 15:18:40 +0000

On Sat, Nov 30, 2013 at 04:07:17PM +0100, Moritz Mühlenhoff wrote:
> [EOD from me due to a lack of time, but that needed to be said]

And thank you for saying it.

-- 
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for hackers

Message #673 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Moritz Mühlenhoff <jmm@inutil.org>

Cc: Michael Stapelberg <stapelberg@debian.org>, 727708@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Sun, 1 Dec 2013 12:11:11 -0600

[Message part 1 (text/plain, inline)]

On Sat, Nov 30, 2013 at 04:07:17PM +0100, Moritz Mühlenhoff wrote:
> On Thu, Nov 28, 2013 at 08:07:16PM -0600, Steve Langasek wrote:
> > All distributions "care" about not having security issues in their code, but
> > that's not the same thing as actually doing the work to audit the code.  In
> > practice this only happens when dedicated resources are turned on the code
> > in question, and having more companies using the code does not magically
> > make that happen.

> [I took care of the systemd DSA people are referring to]

> The issue people are talking about were discovered during a review of the
> Red Hat Product Security Team (most likely triggered by the inclusion of
> systemd into RHEL7).
> So in fact having more companies use the code exactly made that magically
> happen.

No, this is a function of one specific company having a proactive security
review policy (for which they should be commended).  It has nothing to do
with how many companies are using the software.

> More review and more usage will lead to more bugs being found, we should
> rather applaud Red Hat for investing resources and be diligent. After all
> Red Hat is the only distro staffing a proactive product security team
> (from which everyone is profiting outside of RH as well). I don't consider
> the lack of reported security issues for the contenders as a credible 
> indication of them being more secure.

Red Hat shipped upstart as their init system in RHEL 6.  This did not result
in any CVEs being issued for upstart.  What conclusions should we draw from
this?

> FWIW, the main reason I'm personally in favour of adopting systemd is
> precisely security (in terms of sandboxing and restricting services).  See
> http://0pointer.de/blog/projects/security.html for some pointers.

I think such built-in sandboxing features are interesting, but not decisive.
They represent an incremental improvement over the status quo for
sandboxing, and aren't anything that couldn't be delivered as a feature in
upstart, for example, if there were demand for it.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #678 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Sune Vuorela <sune@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Sun, 01 Dec 2013 18:49:51 +0100

On Thursday 28 November 2013 13:43:27 Ian Jackson wrote:
> > CVE		summary					Debian BTS	Redhat
> > 2012-0871	systemd-logind insecure file creation	?		795853

> Furthermore, I think it is fair to look at bugs in non-pid-1 parts of
> the systemd codebase when assessing the likely code quality of the pid
> 1 parts.

Note that the non-pid1-parts of systemd, like logind for example, are pieces 
we need no matter what init system we choose. The question is more if we can 
use them as provided by upstream or we need to adapt them in Debian.

/Sune
-- 
How to close the space bar?

First from the control drawer inside Office 8.7.5 you should ping the site of 
the controller for logging on a BIOS.

Message #683 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 727708@bugs.debian.org, Moritz Mühlenhoff <jmm@inutil.org>, Michael Stapelberg <stapelberg@debian.org>

Subject: Re: Bug#727708: systemd (security) bugs

Date: Sun, 01 Dec 2013 12:22:08 -0800

Steve Langasek <vorlon@debian.org> writes:
> On Sat, Nov 30, 2013 at 04:07:17PM +0100, Moritz Mühlenhoff wrote:

>> The issue people are talking about were discovered during a review of
>> the Red Hat Product Security Team (most likely triggered by the
>> inclusion of systemd into RHEL7).  So in fact having more companies use
>> the code exactly made that magically happen.

> No, this is a function of one specific company having a proactive security
> review policy (for which they should be commended).  It has nothing to do
> with how many companies are using the software.

I don't think that's strictly true.  The more organizations use a piece of
software, the more likely one or more of them will have proactive security
review policies and will do such reviews.  In other words, the size of the
community is relevant to how much security verification software gets.

> I think such built-in sandboxing features are interesting, but not
> decisive.  They represent an incremental improvement over the status quo
> for sandboxing, and aren't anything that couldn't be delivered as a
> feature in upstart, for example, if there were demand for it.

I don't think capability is really the discussion that we're having, at
least in the comparison between systemd and upstart's init components.
The question is more whether there are sufficient resources in the upstart
community that such development is likely.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #688 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org

Cc: Moritz Mühlenhoff <jmm@inutil.org>, Michael Stapelberg <stapelberg@debian.org>

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Sun, 1 Dec 2013 21:22:47 +0100

Hi,

On Sun, 01 Dec 2013, Steve Langasek wrote:
> > More review and more usage will lead to more bugs being found, we should
> > rather applaud Red Hat for investing resources and be diligent. After all
> > Red Hat is the only distro staffing a proactive product security team
> > (from which everyone is profiting outside of RH as well). I don't consider
> > the lack of reported security issues for the contenders as a credible 
> > indication of them being more secure.
> 
> Red Hat shipped upstart as their init system in RHEL 6.

The more interesting information in all this is why RHEL is switching over
from upstart to systemd?

I mean we have an incentive to switch to something else because we can't
reliably fix stuff with sysvinit. But if upstart was satisfactory at that
level, what are the reasons why RHEL is switching again?

Maybe the security features discussed here are part of the answer, I don't
know.

> > FWIW, the main reason I'm personally in favour of adopting systemd is
> > precisely security (in terms of sandboxing and restricting services).  See
> > http://0pointer.de/blog/projects/security.html for some pointers.
> 
> I think such built-in sandboxing features are interesting, but not decisive.
> They represent an incremental improvement over the status quo for
> sandboxing, and aren't anything that couldn't be delivered as a feature in
> upstart, for example, if there were demand for it.

I believe that those who need those features just decide to use systemd
and won't "demand" those features to the upstart upstreams. In particular
when those features are of particular interest to people who are building
heavily customized systems (think embedded devices) and are not wary of
diverging from the defaults.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

Message #693 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Sune Vuorela <sune@debian.org>, 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Sun, 1 Dec 2013 21:50:49 +0000

Sune Vuorela writes ("Bug#727708: systemd (security) bugs (was: init system question)"):
> Note that the non-pid1-parts of systemd, like logind for example, are pieces 
> we need no matter what init system we choose. The question is more if we can 
> use them as provided by upstream or we need to adapt them in Debian.

Whether Debian' "uses" something is a lot more granular than that.
It seems to me that there are plenty of systems which could do without
logind, at least if we're not using systemd as pid 1.

This leads me to a question which I find myself asking, after reading
the systemd debate page:

If we were to adopt systemd as pid 1, which sections of the systemd
source code would we probably want to adopt as well ?  Or to put it
another way, which other existing programs would be obsoleted ?

This is important for two reasons that I can think of:

Firstly, it is touted as an advantage of systemd that it provides in a
good and proper way this other functionality; it seems that the
systemd designers consider that these other ad-hoc programs or
facilities are crufty and in need of replacement.  So I would like to
know which these other facilities are, that are going to be improved.

Secondly, if we are, for example, to compare the total LOC count, or
the bug list, or the CVE history, of systemd, with that of a
non-systemd system, we need to know which parts of the old system are
replaced.

Ian.

Message #698 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 727708@bugs.debian.org

Subject: systemd and support for other distros

Date: Sun, 1 Dec 2013 21:56:28 +0000

In the systemd statement we see:

  Systemd's upstream is very accommodating to distributors. They are
  taking a lot of Debian's needs into account, even though it has not
  yet been decided to make it the default.

The upstart statement says:

  systemd upstream paints a utopian vision where upstream services all
  ship with systemd unit files that Just Work everywhere (despite the
  fact that even trivial failures to comply with Debian policy in
  systemd units submitted upstream by Red Hat employees result in
  non-portable systemd configurations).[1]

The link [1] is to
  https://lists.samba.org/archive/samba-technical/2013-February/090400.html
in which there is a discussion about whether the Samba project ought
to ship a systemd unit file which is compatible with Debian, or one
which only works with distros which have decided to abolish the
distinction between /usr and /.

It's not clear to me from the discussion there exactly what systemd
upstream's position on this kind of thing is.

Can someone point us, for example, to a statement by the systemd
upstreams about their support for separate /usr (or their non-support
for it) ?

Ian.

Message #703 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Sune Vuorela <sune@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Sun, 01 Dec 2013 23:11:43 +0100

On Sunday 01 December 2013 21:50:49 Ian Jackson wrote:
> This leads me to a question which I find myself asking, after reading
> the systemd debate page:
> 
> If we were to adopt systemd as pid 1, which sections of the systemd
> source code would we probably want to adopt as well ?  Or to put it
> another way, which other existing programs would be obsoleted ?

logind is obsoleting consolekit and libpam-xdg. (Consolekit tracks wether or 
not a user is sitting on the physical console or logged in. libpam-xdg ensures 
that XDG_RUNTIME_DIR is handled according to the spec). Logind also ensures 
that a user session actually can be terminated when she logs out.

Logind is the most important one, and within a year or two all desktop 
environments that wants to be slightly more advanced than TWM is going to need 
it. Even Ubuntu is using logind and is iirc maintained there by Steve 
Langasek.

Consolekit was written by the same people as involved in systemd and is now 
hopefully getting it right. Consolekit is abandoned upstream a couple of years 
ago. Libpam-xdg was written by Steve Langasek for Ubuntu and has since been 
abandoned in in Ubuntu favour of the systemd bits .

Beside that, there are among others:
the timezoned is ensuring a common way that applications can get notified when 
the hosts timezone changes. KDE does have something for that that would be 
obsoleted. I think most other systems requires restart of applications or 
manual magic in each app.

hostnamed is for notifying when hostname changes. KDE does have something for 
that. I don't know who else.

There are more parts, but that's where my research has ended so far. 

/Sune
-- 
How to cancel a mailer to the proxy from Flash and from the folder inside DOS 
97?

You must log on a driver to debug a monitor.

Message #708 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 727708@bugs.debian.org, Sune Vuorela <sune@debian.org>

Subject: Re: Bug#727708: systemd (security) bugs

Date: Sun, 01 Dec 2013 14:14:45 -0800

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> If we were to adopt systemd as pid 1, which sections of the systemd
> source code would we probably want to adopt as well ?  Or to put it
> another way, which other existing programs would be obsoleted ?

Yes, that's a good question.  We're already using udev, which is now part
of systemd as I understand it.  We'll clearly want to use logind for at
least GNOME (Ubuntu already does that), and I suspect for other desktop
environments as well.  I think there are some other pieces that may
replace other currently separate desktop components.

It sounded like the new D-Bus service may also be important for desktop
environments.

Another point here is that it's sounding like we'll be using a lot of
those services regardless, at least on systems that need them, which means
that their security track record and bug rate is somewhat irrelevant for
this discussion provided that running systemd doesn't force them to be
running on systems that don't need them.  For example, if desktop
environments using upstart are still going to be running logind, the
logind part loses nothing from running systemd and gains something (easier
integration that we don't have to maintain ourselves).  Similarly for
udev.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #713 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: 727708@bugs.debian.org

Cc: Thomas Goirand <zigo@debian.org>, Josselin Mouette <joss@debian.org>

Subject: initsystem decision process: Finalizing position statements before December 6th.

Date: Sun, 1 Dec 2013 17:40:17 -0800

As discussed in the most recent CTTE meeting, we expect all of the
position statements to be finalized no later than this week. I believe
that only the OpenRC statement is not yet finalized.

CTTE members will be asking questions which are unclear from the
position statements in the next two weeks to make sure that all of the
technical details are understood by the committee. [Non-CTTE members
should feel free to suggest questions too.]

Position statement authors: I will attempt to keep
https://wiki.debian.org/Debate/initsystem updated with links to the
questions (and their summary) in this bug's (#727708) log, but feel free
to answer them before I manage to get that updated. [If you are not
already subscribed to the bug or to debian-ctte, please consider doing
so too.[1]] (Other CTTE members have carte blanche to update that page
too.)

Lets try to keep things moving and cordial so we can make the best
technical decision possible; thanks to everyone for their work so far!


1: I apologize if anyone was missing mail to the bug too; I recently
fixed a bug in EOC which was causing messages not to be sent to all but
the first subscriber.
-- 
Don Armstrong                      http://www.donarmstrong.com

Nearly all men can stand adversity, but if you really want to test his
character, give him power.
 -- Abraham Lincoln

Message #718 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: Don Armstrong <don@debian.org>

Cc: 727708@bugs.debian.org

Subject: Re: initsystem decision process: Finalizing position statements before December 6th.

Date: Mon, 02 Dec 2013 12:56:37 +0800

On 12/02/2013 09:40 AM, Don Armstrong wrote:
> As discussed in the most recent CTTE meeting, we expect all of the
> position statements to be finalized no later than this week. I believe
> that only the OpenRC statement is not yet finalized.

Hi Don,

That's not correct, I have stated it was done (after I confirmed that
with upstream). Sorry if I didn't make this clear enough. So please go
ahead! :)

Thomas

Message #723 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd and support for other distros

Date: Mon, 02 Dec 2013 09:28:23 +0100

]] Ian Jackson 

> It's not clear to me from the discussion there exactly what systemd
> upstream's position on this kind of thing is.
> 
> Can someone point us, for example, to a statement by the systemd
> upstreams about their support for separate /usr (or their non-support
> for it) ?

http://lists.freedesktop.org/archives/systemd-devel/2013-November/014797.html

So they see it as pointless, but will be supported for a long time.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #728 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs

Date: Mon, 2 Dec 2013 11:22:16 +0000

Russ Allbery writes ("Re: Bug#727708: systemd (security) bugs"):
> Another point here is that it's sounding like we'll be using a lot of
> those services regardless, at least on systems that need them, which means
> that their security track record and bug rate is somewhat irrelevant for
> this discussion provided that running systemd doesn't force them to be
> running on systems that don't need them.  [...]

I don't think that's entirely true.  I think it is fair to look at the
security history of other parts of the same project as indicative
regarding code quality.

Ian.

Message #733 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs

Date: Mon, 02 Dec 2013 17:45:08 +0100

Le lundi 02 décembre 2013 à 11:22 +0000, Ian Jackson a écrit : 
> I don't think that's entirely true.  I think it is fair to look at the
> security history of other parts of the same project as indicative
> regarding code quality.

There are two implied assumptions here: 
      * that the same people are developing all components; 
      * that develolpers have the same attention to code quality and
        security in all components they work on.

I don’t think either of them applies to systemd.

-- 
 .''`.        Josselin Mouette
: :' :
`. `'
  `-

Message #738 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Tollef Fog Heen <tfheen@err.no>, 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd and support for other distros

Date: Mon, 2 Dec 2013 11:25:02 -0600

[Message part 1 (text/plain, inline)]

On Mon, Dec 02, 2013 at 09:28:23AM +0100, Tollef Fog Heen wrote:
> ]] Ian Jackson 

> > It's not clear to me from the discussion there exactly what systemd
> > upstream's position on this kind of thing is.

> > Can someone point us, for example, to a statement by the systemd
> > upstreams about their support for separate /usr (or their non-support
> > for it) ?

> http://lists.freedesktop.org/archives/systemd-devel/2013-November/014797.html

> So they see it as pointless, but will be supported for a long time.

Note that the original complaint in the samba upstream discussion was about
hard-coding of paths to system utilities, which a) is not portable between
distributions and b) contradicts Debian policy.

So systemd upstream may support separate /usr, but that doesn't change the
fact that there are still portability issues when one starts writing systemd
units.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #743 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs

Date: Mon, 02 Dec 2013 11:21:35 -0800

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Russ Allbery writes ("Re: Bug#727708: systemd (security) bugs"):

>> Another point here is that it's sounding like we'll be using a lot of
>> those services regardless, at least on systems that need them, which
>> means that their security track record and bug rate is somewhat
>> irrelevant for this discussion provided that running systemd doesn't
>> force them to be running on systems that don't need them.  [...]

> I don't think that's entirely true.  I think it is fair to look at the
> security history of other parts of the same project as indicative
> regarding code quality.

Oh, sure, I do understand that part.  But when trying to draw inferences
there, it's also important to realize that several of those components
were amalgamated after the fact and had different original authors.
systemd is quite the large tent project right now.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #748 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 727708@bugs.debian.org, Tollef Fog Heen <tfheen@err.no>

Subject: Re: Bug#727708: systemd and support for other distros

Date: Mon, 02 Dec 2013 11:24:41 -0800

Steve Langasek <vorlon@debian.org> writes:

> Note that the original complaint in the samba upstream discussion was
> about hard-coding of paths to system utilities, which a) is not portable
> between distributions and b) contradicts Debian policy.

> So systemd upstream may support separate /usr, but that doesn't change
> the fact that there are still portability issues when one starts writing
> systemd units.

They're fairly trivial ones, though, no?  Maintaining a local patch to
change the paths in a systemd unit is certainly way less effort than
maintaining the whole unit.  It's akin to changing the #! paths in
installed scripts, which we do all the time.

(I should say, for full disclosure, that I have never been a fan of the
implications of our "always use PATH" policy for init scripts anyway.  I
feel like init scripts or the equivalent should always start the same
binary, regardless of what other things the system administrator has
installed elsewhere on the system, unless explicitly changed by the
administrator.  Having them honor PATH is too likely to lead to really
strange and difficult-to-diagnose problems, since you get different
behavior when manually running the init script versus when it's started at
boot.)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #753 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Bdale Garbee <bdale@gag.com>

To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org, 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs

Date: Mon, 02 Dec 2013 13:41:41 -0700

[Message part 1 (text/plain, inline)]

Josselin Mouette <joss@debian.org> writes:

> There are two implied assumptions here: 
>       * that the same people are developing all components; 
>       * that develolpers have the same attention to code quality and
>         security in all components they work on.
>
> I don’t think either of them applies to systemd.

Right, this succinctly captures one of my biggest concerns about systemd.

Bdale

[Message part 2 (application/pgp-signature, inline)]

Message #758 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Russ Allbery <rra@debian.org>

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Mon, 2 Dec 2013 16:28:46 -0600

[Message part 1 (text/plain, inline)]

Hi Russ,

On Fri, Nov 01, 2013 at 08:11:38PM -0700, Russ Allbery wrote:
> Steve Langasek <vorlon@debian.org> writes:

> > For the TC decision, what kind of information are you looking for about
> > the plans, beyond "the Ubuntu developers expect to need to address this
> > before upgrading from systemd logind 204 and will hold at 204 until a
> > correct solution is known"?

> I think the right way to put this is that systemd has significant
> development resources behind it and is working in fairly close cooperation
> with both kernel developers and GNOME developers to make available new
> kernel functionality and to provide implementations of various other
> interfaces.  Multiple implementations are good, but there's potentially an
> ongoing stream of development to keep up with, and (putting aside
> arguments about coupling and appropriate ways to integrate that
> functionality) I believe there is a general agreement that functionality
> is desirable and will be used by other software that Debian wants to
> provide.

> So, one question is whether anyone outside of Canonical is in a position
> to help with the heavy development (as opposed to the occasional patch).
> Red Hat is clearly committed to systemd, and there's some convergence
> towards it among other RPM-based distributions, so long-term resources for
> systemd don't seem to be in doubt.  Canonical is a smaller company, and
> does not always have the resources to keep projects for which it is the
> sole upstream vibrant and growing, even when it seems strongly committed
> to them (c.f. bzr).

While it's fair to note that Canonical is a smaller company with fewer
resources than Red Hat, Canonical is certainly not the only company working
on technologies that don't fit into systemd upstream's model.  On the
question of cgroup management for instance, while there's broad consensus
that we want to move to a single-writer model, there is not consensus about
what that single writer should be; at the last on-line Ubuntu Developer
Summit, developers from Canonical and Google discussed how to collaborate
around their respective cgroup technologies (lxc, lcmtfy) to address the
single-writer requirement for non-systemd systems.

  http://summit.ubuntu.com/uds-1311/meeting/21982/core-1311-cgroup-manager/

We're not talking here about whether Google will contribute to upstart
upstream, because this is code which is separate from upstart by design. 
But in the wider ecosystem of projects that exist in parallel to (and are
incompatible with) systemd, there are other players besides Canonical.

For logind, which is the main point of contention with respect to systemd
205 being usable on systems that don't use systemd as init, the main blocker
is, again, around logind's use of init as the cgroup manager.  In that same
UDS session, a decision was taken to provide cgroup manager API
compatibility with systemd via the systemd-shim package, which is a small
Canonical-maintained compatibility layer (not yet in Debian, but that's
easily addressed).  This will enable use of logind 205 on systems running
upstart (or, for that matter, sysvinit).

I don't believe we need to worry about sufficient manpower to keep up with
systemd development.  There are a fair number of people who have resigned
themselves to systemd because they've been led to believe it's the only
option.  If Debian standardizes on upstart, some of these developers will be
interested in collaborating with Debian to provide equivalent functionality
/ compatible interfaces.  It may not be many developers in absolute terms,
but the rate of development for an init system should not be high in
absolute terms either.  The greater Free Software community does not have
inexhaustible patience for projects that are constantly breaking
backwards-compatibility; whether Debian adopts systemd or not, we are going
to care about things like being able to run current systems in
chroots/containers on older (stable) kernels, and we're going to care about
being able to cleanly upgrade from one stable release to the next, and a
revolving door of rapidly changing kernel interface requirements is bad for
the ecosystem as a whole - and will therefore be self-limiting.

> If Canonical *is* the sole upstream, the upstream future here is troubling
> to me, particularly given Canonical's current strategic direction towards
> Unity.  To give a specific example of the sort of thing that I'm worried
> about, suppose that GNOME Shell wants a new piece of functionality that
> is, on Red Hat, provided via kernel functionality managed by systemd, but
> Unity has no need for that functionality.  Is Canonical going to develop
> an upstart equivalent in support of GNOME Shell, when it is pushing Unity
> over GNOME Shell?

> Maybe this example is very artificial; I know it's not clear what piece of
> functionality would be required from the init system and surrounding
> infrastructure that would be required by GNOME Shell and not Unity.  But I
> think it's at least conceivable given different priorities around such
> things as multiseat, and in any case it provides a concrete example of the
> sort of scenario I'm worried about.

Well, I guess you wouldn't expect me to say "yes" here, or if I did, you
wouldn't believe me; it's unrealistic for Canonical to commit to
implementing some arbitrary - and hypothetical - future functionality.
Canonical is committed to being a good steward for upstart for as long as
Ubuntu itself uses it, and welcomes its use by other distributions.  But
this isn't an act of altruism, it's enlightened self-interest.  Canonical
isn't going to make an indefinite committment to maintain features it
doesn't have need for itself.

But I think the same can be said of systemd.  If Debian concluded that
systemd's cgroup manager design was wrong because it embeds it in PID 1,
and wanted systemd to be compatible with other container solutions like lxc
and lmctfy, I don't think we would expect Red Hat to make this happen for
us.

All that said, I think your example /is/ very artificial.  logind is
unquestionably the best solution for seat management today, and there's no
reason to implement a competing solution.  Systemd upstream doesn't want to
support logind on non-systemd systems, but we can reasonably provide the
necessary compatibility layer so that it just works everywhere, for
everyone's benefit.  So in practice, I don't foresee a case where divergent
requirements of Unity vs. GNOME Shell would leave Debian holding the bag.


> In other words, it's not so much a specific roadmap as it is a roadmap
> approach and resource committment.  Debian, by choosing a default init
> system, is potentially investing a lot of developer effort on supporting
> that platform for packaged daemons, somewhat akin to an organization
> choosing a product on which to base a required piece of internal
> functionality.  I'm therefore asking the same sort of question that I
> would ask of a vendor whose products we were evaluating for my day job:
> what guarantees do we have that this product will continue to be developed
> and supported going forward?

> The situation with free software is a bit different from a vendor, of
> course, since Debian could always patch or even pick up development of the
> software ourselves, but I think we'd all agree that Debian ending up
> committed to a system service family (since that's really what we're
> talking about here -- not just the init system itself, but also how the
> equivalents, forks, or refactorings of logind, D-Bus, cgroups, udev, and
> so forth will be handled) whose pace of development has slowed to the
> extent that bzr's has would be a very bad outcome.

bzr lost the DVCS war not because Canonical was unwilling to invest in bzr,
but because git had an early lead in performance and flexibility that made
it the runaway choice for developers, and by the time bzr was catching up in
functionality, network effects meant it was too late.  Once it became clear
that bzr would not deliver on its promise of being a universal DVCS because
the world had already adopted git as a de facto standard, it was reasonable
for Canonical to stop investing in bzr development.

So I don't think there's much similarity between what happened with bzr, and
what would happen with upstart if Debian adopted it.  If Debian adopted
systemd instead of upstart, /then/ there would be hard questions about the
future of upstart, in light of a clear consensus that systemd is the
technically superior option.  But if Debian /does/ adopt upstart, Debian +
Ubuntu represents a critical mass to keep the project going for the
foreseeable future.

> At least superficially, that outcome looks more likely to me with upstart
> than it does with systemd, so I'm looking for some reassurance for why the
> risk of ending up in that situation is low.

Hopefully I've addressed this concern.  If not, please let me know.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #763 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org

Cc: Tollef Fog Heen <tfheen@err.no>

Subject: Re: Bug#727708: systemd and support for other distros

Date: Mon, 2 Dec 2013 16:43:37 -0600

[Message part 1 (text/plain, inline)]

On Mon, Dec 02, 2013 at 11:24:41AM -0800, Russ Allbery wrote:
> Steve Langasek <vorlon@debian.org> writes:

> > Note that the original complaint in the samba upstream discussion was
> > about hard-coding of paths to system utilities, which a) is not portable
> > between distributions and b) contradicts Debian policy.

> > So systemd upstream may support separate /usr, but that doesn't change
> > the fact that there are still portability issues when one starts writing
> > systemd units.

> They're fairly trivial ones, though, no?  Maintaining a local patch to
> change the paths in a systemd unit is certainly way less effort than
> maintaining the whole unit.  It's akin to changing the #! paths in
> installed scripts, which we do all the time.

In this case, the porting requirements are trivial, yes.  My point is that
porting is still required, and systemd units aren't "write once, run
everywhere" the way systemd advocates have claimed.  In my experience, the
cost of a packaging delta is in *maintaining* the delta over time, not in
creating it initially, and a one-line delta to something like a systemd unit
is not measurably less of a maintenance burden than, say, a 20-line delta to
an init script.

> (I should say, for full disclosure, that I have never been a fan of the
> implications of our "always use PATH" policy for init scripts anyway.  I
> feel like init scripts or the equivalent should always start the same
> binary, regardless of what other things the system administrator has
> installed elsewhere on the system, unless explicitly changed by the
> administrator.  Having them honor PATH is too likely to lead to really
> strange and difficult-to-diagnose problems, since you get different
> behavior when manually running the init script versus when it's started at
> boot.)

Sure.  Both systemd and upstart manage to avoid the problem of inconsistent
behavior due to tainted admin environments, because daemons are always
started as children of init and not of the admin's login shell.  That being
the case, hard-coding the path to an executable in your initscript
equivalent doesn't buy you much added protection, compared with just using
the system $PATH, and does cause gratuitous incompatibilities in exactly
those cases that Debian Policy's prohibition on hard-coded paths is meant to
address.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #768 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 727708@bugs.debian.org, Tollef Fog Heen <tfheen@err.no>

Subject: Re: Bug#727708: systemd and support for other distros

Date: Mon, 02 Dec 2013 14:48:52 -0800

Steve Langasek <vorlon@debian.org> writes:
> On Mon, Dec 02, 2013 at 11:24:41AM -0800, Russ Allbery wrote:

>> They're fairly trivial ones, though, no?  Maintaining a local patch to
>> change the paths in a systemd unit is certainly way less effort than
>> maintaining the whole unit.  It's akin to changing the #! paths in
>> installed scripts, which we do all the time.

> In this case, the porting requirements are trivial, yes.  My point is
> that porting is still required, and systemd units aren't "write once,
> run everywhere" the way systemd advocates have claimed.  In my
> experience, the cost of a packaging delta is in *maintaining* the delta
> over time, not in creating it initially, and a one-line delta to
> something like a systemd unit is not measurably less of a maintenance
> burden than, say, a 20-line delta to an init script.

Hm.  I guess what I can say there is that this doesn't match my
experience, mostly because the deltas that I've had to maintain to init
scripts are much more serious than path changes.  Path changes are pretty
easy to maintain over time.  Init scripts have historically required more
serious changes for different helper function libraries, using
Debian-specific tools like start-stop-daemon, and so forth.  In fact, most
of my upstreams have long since given up on trying to write a portable
init script and just have separate ones for each major UNIX variant.

By comparison, path differences are trivial.  As far as I'm concerned,
that still counts as "write once, run everywhere."

> Sure.  Both systemd and upstart manage to avoid the problem of
> inconsistent behavior due to tainted admin environments, because daemons
> are always started as children of init and not of the admin's login
> shell.  That being the case, hard-coding the path to an executable in
> your initscript equivalent doesn't buy you much added protection,
> compared with just using the system $PATH, and does cause gratuitous
> incompatibilities in exactly those cases that Debian Policy's
> prohibition on hard-coded paths is meant to address.

I have never seen a gratuitous incompatibility caused by this.  Do you
have any examples?

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #773 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Sune Vuorela <sune@debian.org>, 727708@bugs.debian.org

Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Mon, 2 Dec 2013 16:56:57 -0600

[Message part 1 (text/plain, inline)]

On Sun, Dec 01, 2013 at 11:11:43PM +0100, Sune Vuorela wrote:
> On Sunday 01 December 2013 21:50:49 Ian Jackson wrote:
> > This leads me to a question which I find myself asking, after reading
> > the systemd debate page:

> > If we were to adopt systemd as pid 1, which sections of the systemd
> > source code would we probably want to adopt as well ?  Or to put it
> > another way, which other existing programs would be obsoleted ?

> logind is obsoleting consolekit and libpam-xdg. (Consolekit tracks wether
> or not a user is sitting on the physical console or logged in.  libpam-xdg
> ensures that XDG_RUNTIME_DIR is handled according to the spec).  Logind
> also ensures that a user session actually can be terminated when she logs
> out.

> Logind is the most important one, and within a year or two all desktop
> environments that wants to be slightly more advanced than TWM is going to
> need it.  Even Ubuntu is using logind and is iirc maintained there by
> Steve Langasek.

It's collectively maintained in Ubuntu; I do help with it, but Martin Pitt
does most of the routine maintenance for the systemd source package (udev,
logind).

> Beside that, there are among others:
> the timezoned is ensuring a common way that applications can get notified
> when the hosts timezone changes.  KDE does have something for that that
> would be obsoleted.  I think most other systems requires restart of
> applications or manual magic in each app.

'timedated'

> hostnamed is for notifying when hostname changes. KDE does have something
> for that.  I don't know who else.

> There are more parts, but that's where my research has ended so far. 

The other one that GNOME uses, and that should be adopted, is localed.

But these dbus services (logind, timedated, hostnamed, localed) are things
that we should adopt, /independently/ of whether systemd is used as pid 1.

I don't know that there are any systemd services that we would want to adopt
IFF we switched to systemd for pid 1.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #778 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs

Date: Tue, 03 Dec 2013 00:03:48 +0100

Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit : 
> Josselin Mouette <joss@debian.org> writes:
> 
> > There are two implied assumptions here: 
> >       * that the same people are developing all components; 
> >       * that develolpers have the same attention to code quality and
> >         security in all components they work on.
> >
> > I don’t think either of them applies to systemd.
> 
> Right, this succinctly captures one of my biggest concerns about systemd.

Could you please elaborate on this concern? Is it about the large number
of developers, or about the fact they treat important pieces of code
more carefully?

-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-

Message #783 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs

Date: Mon, 2 Dec 2013 15:32:33 -0800

On Tue, 03 Dec 2013, Josselin Mouette wrote:
> Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit : 
> > Josselin Mouette <joss@debian.org> writes:
> > 
> > > There are two implied assumptions here: 
> > >       * that the same people are developing all components; 
> > >       * that develolpers have the same attention to code quality and
> > >         security in all components they work on.
> > >
> > > I don’t think either of them applies to systemd.
> > 
> > Right, this succinctly captures one of my biggest concerns about systemd.
> 
> Could you please elaborate on this concern? Is it about the large number
> of developers, or about the fact they treat important pieces of code
> more carefully?

Projects which have multiple components, each of which has different
security/interface surfaces without stable defined interfaces, can lead
to problems when one set of developers doesn't understand the security
implications of the parts that they do not work on.

The combination of components into a single monolith is sometimes
necessary, but it's not clear that it is so in the case of systemd.

-- 
Don Armstrong                      http://www.donarmstrong.com

THERE IS NO GRAVITY THE WORLD SUCKS
 -- Vietnam War Penquin Lighter
http://gallery.donarmstrong.com/clippings/vietnam_there_is_no_gravity.jpg

Message #788 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Uoti Urpala <uoti.urpala@pp1.inet.fi>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs

Date: Tue, 03 Dec 2013 08:17:44 +0200

On Mon, 2013-12-02 at 15:32 -0800, Don Armstrong wrote:
> On Tue, 03 Dec 2013, Josselin Mouette wrote:
> > Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit : 
> > > Josselin Mouette <joss@debian.org> writes:
> > > 
> > > > There are two implied assumptions here: 
> > > >       * that the same people are developing all components; 
> > > >       * that develolpers have the same attention to code quality and
> > > >         security in all components they work on.
> > > >
> > > > I don’t think either of them applies to systemd.
> > > 
> > > Right, this succinctly captures one of my biggest concerns about systemd.
> > 
> > Could you please elaborate on this concern? Is it about the large number
> > of developers, or about the fact they treat important pieces of code
> > more carefully?
> 
> Projects which have multiple components, each of which has different
> security/interface surfaces without stable defined interfaces, can lead
> to problems when one set of developers doesn't understand the security
> implications of the parts that they do not work on.
> 
> The combination of components into a single monolith is sometimes
> necessary, but it's not clear that it is so in the case of systemd.

IMO "single monolith" is bad terminology - to me that sounds something
like everything in a single process, while the systemd components are
quite modular.

"Not clear it's necessary" seems like an overly negative attitude. There
doesn't seem to be much disagreement about the fact that many of the
systemd components are very useful and would be used even with a
different init. The above security considerations seem purely
theoretical, with no sign that they'd be an issue with systemd in
practice. And IIRC no other actual technical problems resulting from
developing the components together have been brought up in this thread
either. So why should it be done any differently, when this way appears
highly successful?

Message #793 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs

Date: Mon, 02 Dec 2013 22:39:09 -0800

Don Armstrong <don@debian.org> writes:

> Projects which have multiple components, each of which has different
> security/interface surfaces without stable defined interfaces, can lead
> to problems when one set of developers doesn't understand the security
> implications of the parts that they do not work on.

It's unclear to me that this is a correct characterization of systemd.  Do
the separate components of systemd not have stable, defined interfaces?  I
know they largely don't have other implementations, but that's not the
same thing.

> The combination of components into a single monolith is sometimes
> necessary, but it's not clear that it is so in the case of systemd.

systemd is a large package from a source code perspective, but it's not my
impression that the result of building that source is a monolith.  Rather,
it's a variety of separate, interoperating services, which strikes me as a
good general model.  In fact, that design is what makes it possible to
consider using upstart and still support GNOME, since it means that logind
is separable from systemd with some effort.  That strongly implies that
systemd is not a monolith.

I think the concern on the systemd side is not stemming from unstable
interfaces but from *evolving* interfaces, which is not the same thing.
In other words, the current systemd services do not implement all the
functionality that will be eventually needed, particularly by desktops, so
those interfaces will grow with time, and may require further D-Bus, udev,
cgroups, and similar integrations.

Let me put it this way.  I think there are a couple of givens here, some
of which have been expressed by both the GNOME maintainers and the KDE
maintainers and which are also reflected by the current state of Ubuntu:

* We use udev as the default device management platform and will continue
  to do so regardless of the init system we choose.

* Many of the other systemd services, particularly logind but also several
  of the others, are quite desirable or even necessary for desktop
  environments, so we will need to adopt those services in Debian
  regardless of what init system we choose.  Obviously, if we adopt
  systemd, integrating those services into the distribution is quite
  straightforward.  If we don't adopt systemd, there are some critical
  missing integrations (relative to the normal systemd infrastructure)
  that will have to be replaced.  The cgroups manager appears to be the
  most significant one at the moment.

If the interfaces for those supplemental components are actually unstable,
that's going to pose problems all around, but I'm not sure how directly
relevant to this discussion that is since we're going to have to deal
with those components *anyway*.  Choosing a different init system than
systemd is not going to let us ignore logind, since it's going to be a
required component for a modern desktop.  (Although it would still be good
to know if this is the case.)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #798 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Date: Mon, 02 Dec 2013 22:55:46 -0800

Steve Langasek <vorlon@debian.org> writes:

> While it's fair to note that Canonical is a smaller company with fewer
> resources than Red Hat, Canonical is certainly not the only company
> working on technologies that don't fit into systemd upstream's model.
> On the question of cgroup management for instance, while there's broad
> consensus that we want to move to a single-writer model, there is not
> consensus about what that single writer should be; at the last on-line
> Ubuntu Developer Summit, developers from Canonical and Google discussed
> how to collaborate around their respective cgroup technologies (lxc,
> lcmtfy) to address the single-writer requirement for non-systemd
> systems.

>   http://summit.ubuntu.com/uds-1311/meeting/21982/core-1311-cgroup-manager/

> We're not talking here about whether Google will contribute to upstart
> upstream, because this is code which is separate from upstart by design.
> But in the wider ecosystem of projects that exist in parallel to (and
> are incompatible with) systemd, there are other players besides
> Canonical.

> For logind, which is the main point of contention with respect to
> systemd 205 being usable on systems that don't use systemd as init, the
> main blocker is, again, around logind's use of init as the cgroup
> manager.  In that same UDS session, a decision was taken to provide
> cgroup manager API compatibility with systemd via the systemd-shim
> package, which is a small Canonical-maintained compatibility layer (not
> yet in Debian, but that's easily addressed).  This will enable use of
> logind 205 on systems running upstart (or, for that matter, sysvinit).

This is useful, thank you.  So you believe that the necessary cgroup
functionality will be easy to maintain going forward in collaboration with
a different cgroup manager?  How far away is this functionality from being
production-ready?  My understanding is that this will need to be tested
and working for jessie.

> I don't believe we need to worry about sufficient manpower to keep up
> with systemd development.  There are a fair number of people who have
> resigned themselves to systemd because they've been led to believe it's
> the only option.  If Debian standardizes on upstart, some of these
> developers will be interested in collaborating with Debian to provide
> equivalent functionality / compatible interfaces.  It may not be many
> developers in absolute terms, but the rate of development for an init
> system should not be high in absolute terms either.

Well, I partly agree with this, but I'll point out that upstart is
currently significantly behind in functionality.  Contrary to some other
expressed opinions here, I personally do not consider systemd's support
for such things as private /tmp or other security and isolation features
to be minor side features or only marginally interesting.  I think these
sorts of features are where the Linux ecosystem is moving, quite quickly,
and Debian badly needs those features as soon as we can get them.  It's
going to take some time to adapt all of our software to use those
features, so the sooner our init system can provide them and we can get
started, the better.

I have a similar question about OpenRC: the lack of this sort of
functionality is, for me, a very serious issue, although one that would be
mitigated by a clear plan to add it that seems likely to happen.

> Well, I guess you wouldn't expect me to say "yes" here, or if I did, you
> wouldn't believe me; it's unrealistic for Canonical to commit to
> implementing some arbitrary - and hypothetical - future functionality.
> Canonical is committed to being a good steward for upstart for as long
> as Ubuntu itself uses it, and welcomes its use by other distributions.
> But this isn't an act of altruism, it's enlightened self-interest.
> Canonical isn't going to make an indefinite committment to maintain
> features it doesn't have need for itself.

> But I think the same can be said of systemd.  If Debian concluded that
> systemd's cgroup manager design was wrong because it embeds it in PID 1,
> and wanted systemd to be compatible with other container solutions like
> lxc and lmctfy, I don't think we would expect Red Hat to make this
> happen for us.

The problem for upstart is that these are not comparable, precisely
because Canonical plays such a smaller role in the broader ecosystem.  For
better or worse, integration with Red Hat and Fedora is extremely
important to most of our upstream projects, and Red Hat provides
significant development resources itself to many upstream projects.  This
means that systemd integration is far more likely to happen without
Debian's assistance than upstart integration.

I think the argument for upstart relies on the assumption that such
integration is not horribly important or normally won't be a serious
issue.  In essence, my understanding of how you view a world with upstart
(and the world that Ubuntu is implementing) is that we will use most of
the systemd services but not its init engine, replacing that and the
cgroup manager with upstart, and still participating in the rest of the
systemd ecosystem.  This sounds quite reasonable provided that it's
relatively straightforward to do this, which is going to depend heavily on
how much core functionality is provided by the init component and how much
is provided by separable services.

> bzr lost the DVCS war not because Canonical was unwilling to invest in
> bzr, but because git had an early lead in performance and flexibility
> that made it the runaway choice for developers, and by the time bzr was
> catching up in functionality, network effects meant it was too late.
> Once it became clear that bzr would not deliver on its promise of being
> a universal DVCS because the world had already adopted git as a de facto
> standard, it was reasonable for Canonical to stop investing in bzr
> development.

True.  However, I'll point out that a similar argument can be made for
systemd.

> So I don't think there's much similarity between what happened with bzr,
> and what would happen with upstart if Debian adopted it.  If Debian
> adopted systemd instead of upstart, /then/ there would be hard questions
> about the future of upstart, in light of a clear consensus that systemd
> is the technically superior option.  But if Debian /does/ adopt upstart,
> Debian + Ubuntu represents a critical mass to keep the project going for
> the foreseeable future.

And this is exactly the assumption that worries me.  Debian certainly has
a lot of great developers, but we're perpetually understaffed to do the
things we've *already* committed to, and the desktop maintenance teams
(for which these issues are the most critical) are also some of the most
under-staffed.  It's not at all clear to me that KDE or GNOME upstream
will be that heavily influenced, in terms of where they put development
resources, by which init system Debian chooses.  I love Debian too, but
it's not clear to me that we swing that much influence with those
particular projects.

Now, that doesn't matter if Debian can use upstart and still "look like
systemd" from the perspective of the features that the desktop systems
care about, such as logind and some of the other services.  And it sounds
like that's what you're saying can happen.  I'm trying to feel out how
plausible that outcome is.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #803 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 727708@bugs.debian.org, joss@debian.org, tfheen@err.no

Subject: systemd code documentation

Date: Mon, 02 Dec 2013 23:17:56 -0800

I should say up-front that I don't consider this to be a decisive issue,
but since it was raised and I did a bit of investigation, I wanted to
report my initial conclusions and see if I missed anything or got anything
wrong.

I did a quick code inspection of the code base for both upstart and
systemd.  This was quite far from any sort of audit, and was necessarily
quite limited.  The goal was to get a quick feel for the code "smell" and
style, and to see how comfortable I would be working on the source base.

First, I'll say that both projects seem like generally well-written C.
They both use well-defined small functions, there isn't a lot of
deeply-nested structure, they both have published coding styles and
clearly adhere to them, and in general both packages strike me as written
by people who knew what they were doing and have been kept up to date.
(By comparison, sysvinit looks like old and somewhat crufty UNIX code and
makes me nervous and uncomfortable, even though it's much simpler.)

That said, on first impression the upstart code struck me as significantly
superior to the systemd code in terms of orientation for a new developer
or someone attempting to isolate bugs, primarily due to substantial
differences in internal documentation.  In systemd, each function seems
well-designed and isolated and does document some of its assumptions with
asserts, which is good style, but there are almost no comments.  Functions
usually don't have leading comments describing when to call them, header
files don't comment functions, files don't have leading comments to orient
the reader towards the purpose of the file, and most of the internal
comments were cryptic to a first-time reader and struck me more as
marginalia than commentary.

By comparison, upstart was lovely code to read.  It uses Doxygen, which I
can take or leave, but more importantly it documents the internal
interfaces and functions and provides much more internal orientation
(although it could still use leading commentary for each file).

My question here is: am I missing something in systemd?  Did I just look
at the wrong files, or not look deeply enough, or is there orientation
documentation somewhere else where I didn't see it?  Is there something
about this comparison that's unfair?

I'll admit that this is a debated point of style, and some programmers
think that regular commentary make the code less readable and tend to
become out-of-date.  I'm in the other camp; I prefer orientation
commentary on each logical block of code, and probably write code that
some people would consider excessively commented.  I think code should
tell a story to someone who is reading it and invite understanding.  (I've
probably read too much Knuth, although I don't think Knuth's method of
doing this worked.)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #808 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs

Date: Tue, 03 Dec 2013 08:59:36 +0100

]] Russ Allbery 

> Don Armstrong <don@debian.org> writes:
> 
> > Projects which have multiple components, each of which has different
> > security/interface surfaces without stable defined interfaces, can lead
> > to problems when one set of developers doesn't understand the security
> > implications of the parts that they do not work on.
> 
> It's unclear to me that this is a correct characterization of systemd.  Do
> the separate components of systemd not have stable, defined interfaces?  I
> know they largely don't have other implementations, but that's not the
> same thing.

http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/

has a table with the various interfaces and their status.

[...]

> Let me put it this way.  I think there are a couple of givens here, some
> of which have been expressed by both the GNOME maintainers and the KDE
> maintainers and which are also reflected by the current state of Ubuntu:
> 
> * We use udev as the default device management platform and will continue
>   to do so regardless of the init system we choose.

Agreed.

> * Many of the other systemd services, particularly logind but also several
>   of the others, are quite desirable or even necessary for desktop
>   environments, so we will need to adopt those services in Debian
>   regardless of what init system we choose.  Obviously, if we adopt
>   systemd, integrating those services into the distribution is quite
>   straightforward.  If we don't adopt systemd, there are some critical
>   missing integrations (relative to the normal systemd infrastructure)
>   that will have to be replaced.  The cgroups manager appears to be the
>   most significant one at the moment.
>
> If the interfaces for those supplemental components are actually unstable,
> that's going to pose problems all around, but I'm not sure how directly
> relevant to this discussion that is since we're going to have to deal
> with those components *anyway*.  Choosing a different init system than
> systemd is not going to let us ignore logind, since it's going to be a
> required component for a modern desktop.  (Although it would still be good
> to know if this is the case.)

TTBOMK, the page listed above is accurate, and yes, I think there are
components we should adopt no matter if we go for systemd or not.
Things like tmpfiles.d aren't terribly complex, but it adds complexity
to each and every init script that needs a writable directory in /run to
handle permissions, ownership and creation, rather than just having a
single declarative file listing what it needs and the bootup process
ensuring that exists.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #813 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: Russ Allbery <rra@debian.org>

Cc: 727708@bugs.debian.org, joss@debian.org

Subject: Re: Bug#727708: systemd code documentation

Date: Tue, 03 Dec 2013 09:09:13 +0100

]] Russ Allbery 


> My question here is: am I missing something in systemd?  Did I just look
> at the wrong files, or not look deeply enough, or is there orientation
> documentation somewhere else where I didn't see it?  Is there something
> about this comparison that's unfair?

Did you see the «Documentation for Developers» section on
http://www.freedesktop.org/wiki/Software/systemd/ ?  It's more of an
overview/design doc than function documentation, but it might be some of
what you're looking for.

I've also forwarded your question to Lennart on IRC, he might have even
more pointers.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #818 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Tollef Fog Heen <tfheen@err.no>

Cc: 727708@bugs.debian.org, joss@debian.org

Subject: Re: Bug#727708: systemd code documentation

Date: Tue, 03 Dec 2013 00:28:52 -0800

Tollef Fog Heen <tfheen@err.no> writes:

> Did you see the «Documentation for Developers» section on
> http://www.freedesktop.org/wiki/Software/systemd/ ?  It's more of an
> overview/design doc than function documentation, but it might be some of
> what you're looking for.

> I've also forwarded your question to Lennart on IRC, he might have even
> more pointers.

This documentation is really, really nice, but it's a bit different than
what I was talking about.  I should be clear, though (and please also do
mention this to Lennart): the user-facing and the integration
documentation for systemd seems quite good.  This is more the code-level,
helping the programmer sort of documentation, which is a bit lower-level.

Both upstart and systemd seem to have excellent manuals and high-level
design and interface documentation.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #823 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Sergey B Kirpichev <skirpichev@gmail.com>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Tue, 3 Dec 2013 17:14:54 +0400

On Sun, Dec 01, 2013 at 09:50:49PM +0000, Ian Jackson wrote:
> If we were to adopt systemd as pid 1, which sections of the systemd
> source code would we probably want to adopt as well ?  Or to put it
> another way, which other existing programs would be obsoleted ?

Again, very good question.  And answer to this on the debate page is
very worrying, assuming that security concerns were unresolved yet.
(e.g.: CVE-2012-1101 or CVE-2013-4393 examples in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#583)

Personally, as maintainer of the monit package I have objections
against statement:
> Systemd’s service monitoring replaces most uses of daemontools,
> runit, monit, and maybe other similar packages.
This may be correct for daemontools/runit, but not for monit or any
other application-level utility ("if failed port 80 protocol http and
request ... then restart") for proactive monitoring (for example,
zabbix has similar functional).

But systemd can cause conflicts (this depends on the adopted
systemd's default configuration) and so, can create hard-to-debug problems here.

Another questionable statement:
> Most of these bugs have been found by the Red Hat Product security
> team conducting an audit of the code as part of its inclusion in
> their enterprise distribution. Therefore, systemd's security record
> cannot reasonably be compared with implementations that didn’t
> undergo similar audits.

Both upstart and sysvinit were part of RHEL.  Please explain
the difference.

PS:
And just a side note.  It's only my own impression,
that there is too many hate/love around systemd?
Personally, during conversation with the systemd's
wiki page maintainer, I was impressed how many prejudments
he can made and how fast (already after the first letter).
This public disscussion is not an exception:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#628

Why nginx author doesn't have any needs to explain why his
software is superior to apache/lighttpd/etc in vast range
of usecases and so on?  And this is not unusual for other
projects.  Why?

If this situation is so specific for systemd, we
should count this as an argument against.  Is there
any similar example from the debian history?

Message #828 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Eugene Zhukov <jevgeni.zh@gmail.com>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd code documentation

Date: Tue, 3 Dec 2013 17:12:52 +0200

Russ Allbery <rra@debian.org> writes:

> This documentation is really, really nice, but it's a bit different than
> what I was talking about.  I should be clear, though (and please also do
> mention this to Lennart): the user-facing and the integration
> documentation for systemd seems quite good. This is more the code-level,
> helping the programmer sort of documentation, which is a bit lower-level.

The frequency of comments sometimes reflects poor quality of code.
When you feel compelled to add a comment, consider rewriting the code
to make it clearer.

Just my two cents,
Eugene

Message #833 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd code documentation

Date: Tue, 3 Dec 2013 15:33:01 +0000

Eugene Zhukov writes ("Bug#727708: systemd code documentation"):
> The frequency of comments sometimes reflects poor quality of code.
> When you feel compelled to add a comment, consider rewriting the code
> to make it clearer.

Please can we avoid arguing about this particular bikeshed here.

Thanks are due to Russ for his research.

Ian.

Message #838 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Eugene Zhukov <jevgeni.zh@gmail.com>

Cc: 727708@bugs.debian.org

Subject: Re: Bug#727708: systemd code documentation

Date: Tue, 03 Dec 2013 09:46:50 -0800

Eugene Zhukov <jevgeni.zh@gmail.com> writes:

> The frequency of comments sometimes reflects poor quality of code.  When
> you feel compelled to add a comment, consider rewriting the code to make
> it clearer.

That would indeed be a succinct statement of the other perspective on code
comments, which as mentioned in my original message is a perspective that
I understand but disagree with.  :)

The fact that this is disputed and to some degree a matter of style is a
large part of why I mentioned that I don't consider this difference
decisive.

That said, I really do recommend upstart as an example of a nicely-written
and readable code base, although that's partly because much of it is
written the way I would have written that code.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #843 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: 727708@bugs.debian.org

Subject: upstart (security) bugs

Date: Tue, 03 Dec 2013 19:42:39 +0100

Hi,

a friend of mine mentioned (not in a pub, but in a serious discussion
about systemd & upstart) that he looked into upstart bugs more closely,
and found an alarming trend of security bugs that were not flagged as
such. 

I do not share his accusations of bad faith; after all, Ubuntu being
both upstream and downstream for this piece of software, it is
understandable that some developers focus on fixing bugs quickly rather
than asking for CVE numbers. However, I find this habit of not
registering CVEs worrying for two reasons.

     1. It is the sign of insufficient security awareness from some
        developers. Even if Debian were to adopt upstart and make these
        habits change, it is plausible that some developers would not
        take appropriate measures, should new bugs be found. 
     2. If we are to consider past security issues (which again, is
        normal in any software package, even well designed) as a metric
        for the current security status of available init systems, I am
        afraid we are lacking data on upstart.

I don’t know whether Jef’s list is complete. It would be nice if someone
had the time to dig into old upstart bugs to see which ones would have
mandated a security label.


        -------- Message transféré --------
        De: Jef Spaleta <jspaleta@gmail.com>
        À: Josselin Mouette <joss@debian.org>
        Sujet: Re: FYI: for the systemd security debate.
        Date: Mon, 2 Dec 2013 23:39:59 -0900
        
        Evening,
        
        So looking deeper into the upstart bug tracker..... I just don't think
        people have bothered filing CVE requests against upstart at
        all..ever...for anything..even though there have clearly been some
        SERIOUS system security impacting bugs that have reached users in
        Ubuntu releases.
        
        here's an example of a file descriptor leak in upstart, with exploit
        code which could cause a service level DoS be chewing up all available
        file descriptors. Canonical did an internal review...didn't request a
        cve or external impact accessment..and decided it was a normal bug
        fix.
        https://bugs.launchpad.net/upstart/+bug/83099
        The severity of this is basically the same level of the journald
        related CVE-2013-4393
        
        here is an example of a simple programming mistake that lead to a user
        space upstart job causing the pid 1 process to fall over and die.
        Fixed in an update... no CVE requested.
        https://bugs.launchpad.net/upstart/+bug/807293
        This is pretty severe. unprivledge user job taking down pid 1 entirely.
        
        Here's an example of a FULL ROOT ACCESS exploit from console.  Fixed
        release in Ubuntu with an update... no CVE.
        https://bugs.launchpad.net/upstart/+bug/63852
        
        So here's the big problem with looking at CVEs.  Single distribution
        solutions... like upstart...are much much less likely to use the CVE
        system at all to register security issues.
        
        You deep dive into upstart's bug tracker on launchpad, and your going
        to keep finding more and more examples of classic security impact
        bugs..just noone is actually labelling them as security impacters. The
        worrisome thing here is that Canonical and the Ubuntu release
        management have NOT felt the need to classify the problems as security
        impactors. If  had a dog in the debian fight, I'd be very very tempted
        to call the lack of CVEs on these past security issues bad faith...as
        if Canonical was trying to purposely avoid calling attention to the
        severity of these problems.  But I do love bug 63852...its a very
        elegant backdoor on the console.
        
        
        -jef


-- 
 .''`.        Josselin Mouette
: :' :
`. `'
  `-

Message #848 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org

Subject: Re: Bug#727708: upstart (security) bugs

Date: Tue, 3 Dec 2013 19:11:45 +0000

Josselin Mouette writes ("Bug#727708: upstart (security) bugs"):
> I do not share his accusations of bad faith; [...]

It is not appropriate to post these accusations of bad faith to Debian
forums, even if you are quoting an email from someone else, and
whether you add a rider of this kind or not.

Thanks,
Ian.

Message #853 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Bdale Garbee <bdale@gag.com>

To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org, 727708@bugs.debian.org

Subject: Re: Bug#727708: upstart (security) bugs

Date: Tue, 03 Dec 2013 12:50:11 -0700

[Message part 1 (text/plain, inline)]

Josselin Mouette <joss@debian.org> writes:

> a friend of mine mentioned (not in a pub, but in a serious discussion
> about systemd & upstart) that he looked into upstart bugs more closely

Thanks to Jef for this work, the results and his comparison of some bugs
to systemd CVEs is quite interesting.

> However, I find this habit of not registering CVEs worrying...

Your point is taken.  I think no matter what decision we make here,
there will always be some bugs that fall on either side of the "to CVE
or not to CVE" line that we could choose to quibble about in hindsight.

> It would be nice if someone had the time to dig into old upstart bugs
> to see which ones would have mandated a security label.

Perhaps.  I think the point has been made, however, so spending more
time on this might not really add anything new to the discussion.  What
we really care about is the current quality of the code and the
probability of issues in the future, after all, not so much what's in
the past.

Bdale

[Message part 2 (application/pgp-signature, inline)]

Message #856 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: debian-ctte@lists.debian.org

Subject: Re: Bug#727708: systemd (security) bugs

Date: Tue, 3 Dec 2013 11:16:17 -0800

On Tue, 03 Dec 2013, Tollef Fog Heen wrote:
> ]] Russ Allbery 
> > Don Armstrong <don@debian.org> writes:
> > 
> > > Projects which have multiple components, each of which has
> > > different security/interface surfaces without stable defined
> > > interfaces, can lead to problems when one set of developers
> > > doesn't understand the security implications of the parts that
> > > they do not work on.
> > 
> > It's unclear to me that this is a correct characterization of
> > systemd. Do the separate components of systemd not have stable,
> > defined interfaces? I know they largely don't have other
> > implementations, but that's not the same thing.
> 
> http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
> 
> has a table with the various interfaces and their status.

This was useful; thanks for linking to this.

[...]

> > If the interfaces for those supplemental components are actually
> > unstable, that's going to pose problems all around, but I'm not sure
> > how directly relevant to this discussion that is since we're going
> > to have to deal with those components *anyway*.

Right; I think we definitely should integrate many of the components
that are being developed. I'm just concerned that the
component<->systemd interface is still changing, and because the
codebase is integrated, there's less of a requirement to communicate and
document what that interface is than there would be if they were
distinct projects.

This concern isn't very strong, but it was piqued when udev development
was brought into systemd; I'm still not certain why that was necessary.

-- 
Don Armstrong                      http://www.donarmstrong.com

It is easier to build strong children than to repair broken men.
 -- Frederick Douglass


-- 
To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20131203191617.GR4756@rzlab.ucr.edu

Message #861 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@inutil.org>

To: Steve Langasek <vorlon@debian.org>

Cc: Michael Stapelberg <stapelberg@debian.org>, 727708@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>

Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)

Date: Tue, 3 Dec 2013 22:00:29 +0100

On Sun, Dec 01, 2013 at 12:11:11PM -0600, Steve Langasek wrote:
> > More review and more usage will lead to more bugs being found, we should
> > rather applaud Red Hat for investing resources and be diligent. After all
> > Red Hat is the only distro staffing a proactive product security team
> > (from which everyone is profiting outside of RH as well). I don't consider
> > the lack of reported security issues for the contenders as a credible 
> > indication of them being more secure.
> 
> Red Hat shipped upstart as their init system in RHEL 6.  This did not result
> in any CVEs being issued for upstart.  What conclusions should we draw from
> this?

None. The RH Product Security Team didn't exist back then (founded 1.5 years ago).

Cheers,
        Moritz

Message #866 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org

Subject: Re: Bug#727708: upstart (security) bugs

Date: Tue, 3 Dec 2013 18:54:51 -0600

[Message part 1 (text/plain, inline)]

On Tue, Dec 03, 2013 at 07:42:39PM +0100, Josselin Mouette wrote:

>         -------- Message transféré --------
>         De: Jef Spaleta <jspaleta@gmail.com>
>         À: Josselin Mouette <joss@debian.org>
>         Sujet: Re: FYI: for the systemd security debate.
>         Date: Mon, 2 Dec 2013 23:39:59 -0900
>         
>         Evening,
>         
>         So looking deeper into the upstart bug tracker..... I just don't think
>         people have bothered filing CVE requests against upstart at
>         all..ever...for anything..even though there have clearly been some
>         SERIOUS system security impacting bugs that have reached users in
>         Ubuntu releases.

>         here's an example of a file descriptor leak in upstart, with
>         exploit code which could cause a service level DoS be chewing up
>         all available file descriptors.  Canonical did an internal
>         review...didn't request a cve or external impact accessment..and
>         decided it was a normal bug fix.
>         https://bugs.launchpad.net/upstart/+bug/83099
>         The severity of this is basically the same level of the journald
>         related CVE-2013-4393

It does appear to me that this bug should have been treated as a security
bug, but for some reason the developers who did the analysis at the time
felt that "the potential impact on [the affected Ubuntu release] is
negligible".  I don't know why, but all other things being equal, I would
assume that they're right that it wasn't exploitable in the release in
question and therefore didn't warrant a CVE.

This bug is also six years old.  I don't think it makes sense to judge any
project by how bugs were being handled 6 years ago.

>         here is an example of a simple programming mistake that lead to a
>         user space upstart job causing the pid 1 process to fall over and
>         die.  Fixed in an update...  no CVE requested.
>         https://bugs.launchpad.net/upstart/+bug/807293
>         This is pretty severe. unprivledge user job taking down pid 1
>         entirely.

It is a severe error, but it was only exploitable in a configuration that no
one ever shipped.  RHEL6 shipped with upstart 0.6.5, which predated the
changes upstream to allow user sessions (first introduced in release 0.9.0).
SuSE shipped upstart 0.3.9.  Ubuntu shipped 0.9.7, which did have the bug,
but with a dbus configuration that prohibited non-root access to the
problematic calls.  As there were no known downstreams affected by this
issue in practice, we did not consider this to warrant a CVE.

>         Here's an example of a FULL ROOT ACCESS exploit from console. 
>         Fixed release in Ubuntu with an update...  no CVE. 
>         https://bugs.launchpad.net/upstart/+bug/63852

This bug only affected a pre-release version of Ubuntu... seven years ago. 
The bug is marked as being present only in the Ubuntu-specific packaging. 
We are generally not in the habit of requesting CVEs for prerelease-only
issues.

> I do not share his accusations of bad faith; after all, Ubuntu being
> both upstream and downstream for this piece of software, it is
> understandable that some developers focus on fixing bugs quickly rather
> than asking for CVE numbers. However, I find this habit of not
> registering CVEs worrying for two reasons.

>      1. It is the sign of insufficient security awareness from some
>         developers. Even if Debian were to adopt upstart and make these
>         habits change, it is plausible that some developers would not
>         take appropriate measures, should new bugs be found. 
>      2. If we are to consider past security issues (which again, is
>         normal in any software package, even well designed) as a metric
>         for the current security status of available init systems, I am
>         afraid we are lacking data on upstart.

A careful analysis of the presented bugs does not support this conclusion.
If a security-relevant bug had turned up in upstart that affected a release
that was being used downstream, we would certainly take that seriously and
follow all the relevant procedures (CVE request, cross-vendor notification,
etc.)  In practice, TTBOMK this has never been the case.

Certainly, any bug that had warranted a security update in an Ubuntu stable
release would have received a CVE assignment.  There haven't been any of
those.

> I don’t know whether Jef’s list is complete. It would be nice if someone
> had the time to dig into old upstart bugs to see which ones would have
> mandated a security label.

I think that would be a great waste of the tech committee's time and
attention.  When you start digging for security issues in prerelease code
that doesn't /warrant/ a CVE, this is no longer an apples-to-apples
comparison.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #871 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Marko Randjelovic <markoran@eunet.rs>

To: 727708@bugs.debian.org

Subject: Abstract Init Scripts

Date: Wed, 4 Dec 2013 10:28:06 +0100

[Message part 1 (text/plain, inline)]

I made an example script that could serve as a starting point for
controlling all services. User/Admin can override functions from this
script to make custom behavior and configure it in a config file.

It probably doesn't work, but for now it's enough to read it because
it's self-explaining and illustrate the thesis that features that are
missing from sysvinit/initscripts can be implemented in a relatively
simple way.

[example.conf (application/octet-stream, attachment)]

[service (application/octet-stream, attachment)]

Message #876 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: Russ Allbery <rra@debian.org>

Cc: 727708@bugs.debian.org

Subject: [Lennart Poettering] Re: [Russ Allbery] systemd code documentation

Date: Sat, 07 Dec 2013 09:15:35 +0100

[Message part 1 (text/plain, inline)]

I forwarded your question about code documentation to Lennart, and the
attached mail is his answer.

[Message part 2 (message/rfc822, inline)]

From: Lennart Poettering <lennart@poettering.net>

To: Tollef Fog Heen <tfheen@err.no>

Subject: Re: [Russ Allbery] systemd code documentation

Date: Fri, 6 Dec 2013 15:35:21 +0100

On Thu, 05.12.13 22:19, Tollef Fog Heen (tfheen@err.no) wrote:

> 
> Hiya,
> 
> I poked you on IRC about this, but I suspect it disappeared in the
> noise.  Any chance you could point Russ at any other resources that he
> should use?  You can read the entire bug log at
> http://bugs.debian.org/727708 ; Russ's message is
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#803 .
> 
> (Feel free to respond to the bug at 727708@bugs.debian.org too, of
> course.)

Our general approach there is that comments shouldn't drown code. Hence:
comments for everything that cannot be obviously read from the sources,
but not comments for everything we ever write. For example, if you have
a function that is called let's say "unit_load()" then this is already
indicative enough of what the thing does (loads a unit), that we
explicitly do not put a comment there.

Note that our public APIs are documented in man pages, and those are not
placed in the code. You could probably make our statistics look better
in the eyes of the the-more-comments-the-better fraction if we'd not
build those man pages from docbook but rather from inline source code
comments. (I'd even be willing to do that, but I know of no tool that
would allow embedding docbook man XML in C files)

Anyway, no doubt Upstart has more comments. And no doubt we probably
could add mor to our sources. But ultimately this doesn't affect our
contributor base too much as it turns out, since we have so many more
contributors to our code than Upstart got... ;-)

Also, I am pretty sure that Knuth' commenting style is rather extreme
(and didn't drown one of Debian's own projects, ifupdown so that nobody
wanted to hack on it anymore?) I am pretty sure Knuth commenting makes
sense for writing books and for inner core algorithms, but our code is
not like that. The identifiers we use should mostly be sufficient to
indicate things.

Ultimately it's a matter of taste I figure...

Lennart

-- 
Lennart Poettering, Red Hat

[Message part 3 (text/plain, inline)]

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #881 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: 727708@bugs.debian.org

Subject: Aribtrarily breaking working interfaces?

Date: Thu, 12 Dec 2013 23:26:29 +0000

Hi, committee members!

I've been following #725714 with interest in the last few days. It
seems that the arbitrary breakage of the module/firmware loading
interface in udev last year [1] is now causing major issues for us and
our users in debian-installer.

I'm very concerned that exactly this kind of long-term breakage is
likely to be a future problem with systemd...

[1] http://lwn.net/Articles/518942/
-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray

Message #886 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Michael Stapelberg <stapelberg@debian.org>

To: Steve McIntyre <steve@einval.com>, <727708@bugs.debian.org>

Subject: Re: Aribtrarily breaking working interfaces?

Date: Fri, 13 Dec 2013 08:23:55 +0100

Hi Steve,

Steve McIntyre <steve@einval.com> writes:
> I've been following #725714 with interest in the last few days. It
> seems that the arbitrary breakage of the module/firmware loading
> interface in udev last year [1] is now causing major issues for us and
> our users in debian-installer.
I take offense with the fact that you write “arbitrary breakage”.

It implies that Kay et al. (udev upstream) _arbitrarily_ decided (as
opposed to “with good reason, after careful consideration”) to break
that interface.

I do not have the impression that this is the case. And I certainly do
not see any evidence supporting that.

So please, can we assume good faith when talking about other human
beings that are involved in our community?

-- 
Best regards,
Michael

Message #891 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Steve McIntyre <steve@einval.com>, 727708@bugs.debian.org

Subject: Re: Bug#727708: Aribtrarily breaking working interfaces?

Date: Fri, 13 Dec 2013 11:27:01 +0000

Steve McIntyre writes ("Bug#727708: Aribtrarily breaking working interfaces?"):
> [1] http://lwn.net/Articles/518942/

Blimey.  I hadn't been aware of that.  Have there been more of these
disputes between the kernel and udev maintainers ?

Ian.

Message #896 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 727708@bugs.debian.org, Steve McIntyre <steve@einval.com>

Subject: Re: Bug#727708: Aribtrarily breaking working interfaces?

Date: Fri, 13 Dec 2013 10:52:40 -0800

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Steve McIntyre writes:

>> [1] http://lwn.net/Articles/518942/

> Blimey.  I hadn't been aware of that.  Have there been more of these
> disputes between the kernel and udev maintainers ?

I think it's worth noting that the very first comment on that news article
is a note that the issue was already fixed in udev, independent of the
move of firmware loading to the kernel, with a link to a perfectly
reasonable-looking fix in Git.

LWN, like most journalists, have a vested interest in making stories
sensational.  I'm not a fan of the way Linux development discussion is
handled (most issues turn into these ranting contests), but by and large
they do converge on some reasonable solution rather quickly.

This whole thing looks like a tempest in a teapot to me.  Linux kernel
development is very good at creating those; the project is rather
pathological that way.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #901 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 727708@bugs.debian.org

Subject: upstart user jobs

Date: Sat, 14 Dec 2013 12:31:57 +0000

I have some questions about these.  Forgive me if I could just have
looked up the answers:

Are they enabled by default in jessie/sid ?
(If the answer is "no" then feel free not to answer the rest...)

In the manpage I read:
  | Note that a user job configuration file cannot have the same name
  | as a system job configuration file.
I don't understand this restriction.  It's sounds like it's referring
to the pathnames in which case it's trivially true, so I assume it's
referring to job names.  In which case surely this is a troublesome
restriction: what, for example, if a user, knowing that the sysadmin
is going to install something that creates job "foo", creates a job
"foo" themselves first ?  Can two different users create two jobs with
the same name ?  The underlying purpose of the restriction would seem
to probably be to make job names unqualified by username but unique
across users, but that seems wrong to me.

Does anything that user jobs do depend on upstart being pid 1, or
being root ?  Does the thing which reads (and watches) the user's
configuration files run as root, or as the user ?  I.e., what is the
privilege separation ?

The docs say:
 | Files in this directory will be read and an inotify(7) watch
 | created the first time a user runs initctl(8).
Does this really mean that if I'm fiddling around with writing some
jobs, but not quite ready yet, and say "initctl --help", my jobs will
start to run ?  Also, it would appear to imply that user jobs aren't
started automatically at boot.

Thanks,
Ian.

Message #906 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 727708@bugs.debian.org

Subject: upstart proposed policy in Debian

Date: Sat, 14 Dec 2013 13:36:59 +0000

Having read the docs there I have some apparently unanswered questions
about how the upstart proponents think we would use upstart in Debian.

How will we cope with removed-but-not-purged services ?

Do we advise people in favour of socket activation ?

Do we deprecate "expect fork" and "expect daemon" ?  (I would favour
this - the approach there is pretty horrible.)

Perhaps there is some ubuntu docs on this.  I confess I didn't try
very hard to find it, hoping we might have a suitable Ubuntu upstart
expert on hand :-).

Thanks,
Ian.

Message #911 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 727708@bugs.debian.org

Subject: Re: upstart proposed policy in Debian

Date: Sat, 14 Dec 2013 20:28:25 +0000

Ian Jackson writes ("upstart proposed policy in Debian"):
> Having read the docs there I have some apparently unanswered questions
> about how the upstart proponents think we would use upstart in Debian.

I found policy 9.11.1 which I had unaccountably failed to notice
before.  It answer the question of how to do the transition from
sysvinit to upstart, with a hideous shell rune.  Perhaps the upstart
package could provide a cooked command and then we could all say

  if init-is-upstart 2>/dev/null; then exit 1; fi

or something.  (IIRC some comments earlier in this thread about some
corner cases during upgrades; perhaps my suggestionn would help there
too.)

It didn't answer my other questions.

Thanks,
Ian.

Message #916 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 727708@bugs.debian.org

Subject: systemd socket activation protocol rationale

Date: Sat, 14 Dec 2013 21:45:48 +0000

I've just been reading sd_listen_fds(3).  It's vaguely similar to
upstart's socket activation protocol.  It supports multiple sockets
(which is obviously important).

But I have a few questions about the details:

Why do only some of the environment variables start "SD_" ?
We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START.

What is the rationale behind the use of the LISTEN_PID variable and
the pid check ?  It seems to me that at the very least this might make
it hard to wrap up a socket-activated daemon in a shell script.

I think it would be good, regardless of what the TC decides on the
init system question for Debian, for systemd and upstart to converge
on a single reasonable protocol.

I observe that upstart's UPSTART_FDS, if extended to multiple sockets,
would require the daemon to do whitespace-separated parsing to extract
the (perhaps noncontiguous) fds.  Whereas systemd's two separate
variables and use of a contiguous fd range is slightly easier to deal
with.

AFAICT it might be possible for both daemons to implement both
protocols.  upstart would have to arrange to make sure that if there
were multiple fds they were consecutive.

Observations and/or opinions from either upstart or systemd welcome.

Ian.

Message #921 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 727708@bugs.debian.org

Subject: systemd and upstart (mostly docs) bugs submitted

Date: Sat, 14 Dec 2013 21:59:18 +0000

I've been RTFMing upstart and systemd.  This has generated a number of
bug reports.  In case these are at of any interest here's a list.  If
anything particularly interesting happens in them, I'll mention it.

#732127 [n| ]  Does setuid also set the group(s) ? It should.
#732122 [m| ]  semantics of boolean event specification not defined in init(5)
#732123 [m| ]  usage of "stanza" not compatible with ordinary English
#732125 [m| ]  upstart-events(7) title is misleading
#732126 [m| ]  state machine semantics of "initctl restart" are unclear
#732128 [m| ]  Manpages missing cross-references to socket stuff
#732130 [m| ]  Please document event/job/process environment variables properly
#732131 [m| ]  Please document apparmor directives

#732156 [m| ]  Precise documentation for ExecStart command syntax
#732157 [w| ]  Want SIGSTOP-style daemon/service readiness notification

I haven't yet finished with systemd's docs but I'm going to be doing
something else today soon so I'll send this mail now.

Thanks,
Ian.

Message #926 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 727708@bugs.debian.org

Subject: Re: systemd and upstart (mostly docs) bugs submitted

Date: Sat, 14 Dec 2013 22:01:20 +0000

Ian Jackson writes ("systemd and upstart (mostly docs) bugs submitted"):
> I've been RTFMing upstart and systemd.  This has generated a number of
> bug reports.  In case these are at of any interest here's a list.  If
> anything particularly interesting happens in them, I'll mention it.

I missed two:

> #732127 [n|] Does setuid also set the group(s) ? It should.
> #732122 [m|] semantics of boolean event specification not defined in init(5)
> #732123 [m|] usage of "stanza" not compatible with ordinary English
> #732125 [m|] upstart-events(7) title is misleading
> #732126 [m|] state machine semantics of "initctl restart" are unclear
> #732128 [m|] Manpages missing cross-references to socket stuff
> #732130 [m|] Please document event/job/process environment variables properly
> #732131 [m|] Please document apparmor directives
  #732124 [w|] "initctl reload" behaviour should be configurable in job file
  #732132 [w|] Want support for multiple-socket activation

> #732156 [m|] Precise documentation for ExecStart command syntax
> #732157 [w|] Want SIGSTOP-style daemon/service readiness notification

Ian.

Message #931 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Uoti Urpala <uoti.urpala@pp1.inet.fi>

To: 727708@bugs.debian.org

Subject: Re: systemd socket activation protocol rationale

Date: Sun, 15 Dec 2013 00:36:45 +0200

On Sat, 2013-12-14 at 21:45 +0000, Ian Jackson wrote:
> I've just been reading sd_listen_fds(3).  It's vaguely similar to
> upstart's socket activation protocol.  It supports multiple sockets
> (which is obviously important).
> 
> But I have a few questions about the details:
> 
> Why do only some of the environment variables start "SD_" ?
> We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START.

You misread it: there is no environment variable SD_LISTEN_FDS_START.
The API defines the start value as the constant 3. There is a
corresponding #define in sd-daemon.h, but it is not communicated at
runtime.


> What is the rationale behind the use of the LISTEN_PID variable and
> the pid check ?  It seems to me that at the very least this might make
> it hard to wrap up a socket-activated daemon in a shell script.

To ensure that the environment values are never accidentally inherited
by any child process.

Message #936 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Michael Stapelberg <stapelberg@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, <727708@bugs.debian.org>

Cc: "Helmut Grohne" <helmut@subdivi.de>

Subject: Re: systemd socket activation protocol rationale

Date: Sat, 14 Dec 2013 23:53:42 +0100

Hi Ian,

[still sending this after Uoti’s reply, because my version has some more
detail]

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Why do only some of the environment variables start "SD_" ?
> We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START.
SD_LISTEN_FDS_START is a #define from sd-daemon.h, not an environment
variable.

> What is the rationale behind the use of the LISTEN_PID variable and
> the pid check ?  It seems to me that at the very least this might make
“In addition we set $LISTEN_PID to the PID of the daemon that shall
 receive the fds, because environment variables are normally inherited
 by sub-processes and hence could confuse processes further down the
 chain” ¹

> it hard to wrap up a socket-activated daemon in a shell script.
I am not entirely sure what use cases you have in mind, but typically a
wrapper script at some point just execs the daemon itself, right? In
that case, it’s not a problem.

> I think it would be good, regardless of what the TC decides on the
> init system question for Debian, for systemd and upstart to converge
> on a single reasonable protocol.
Helmut Grohne has done some work in that direction², speaking to the
relevant people at DebConf 13 in person. I am not entirely sure about
the current status of these efforts, maybe Helmut can comment…?

① http://0pointer.de/blog/projects/systemd.html, feature 8
② https://lists.debian.org/debian-devel/2013/06/msg00007.html

-- 
Best regards,
Michael

Message #941 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Helmut Grohne <helmut@subdivi.de>

To: Michael Stapelberg <stapelberg@debian.org>

Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org

Subject: Re: systemd socket activation protocol rationale

Date: Sun, 15 Dec 2013 09:26:21 +0100

On Sat, Dec 14, 2013 at 11:53:42PM +0100, Michael Stapelberg wrote:
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > I think it would be good, regardless of what the TC decides on the
> > init system question for Debian, for systemd and upstart to converge
> > on a single reasonable protocol.
> Helmut Grohne has done some work in that direction², speaking to the
> relevant people at DebConf 13 in person. I am not entirely sure about
> the current status of these efforts, maybe Helmut can comment????

See http://bugs.debian.org/732179. (Afaik you cannot create a new bug
and CC another at the same time. That's why I split the messages.)

Helmut

Message #946 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org

Subject: Re: systemd socket activation protocol rationale

Date: Mon, 16 Dec 2013 05:01:59 +0100

> hard to wrap up a socket-activated daemon in a shell script
There's always systemd-activate, if you really need to do it from the shell :)

Message #951 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@stusta.de>

To: Josselin Mouette <joss@debian.org>

Cc: 727708@bugs.debian.org

Subject: systemd jessie -> jessie+1 upgrade problems

Date: Mon, 16 Dec 2013 17:52:24 +0200

Hi Josselin,

reading through the systemd position statement [1], I ran into a 
statement that is either incomplete or incorrect:


The upstart position statement [2] states:

<--  snip  -->

systemd is hasty. ... While we are committed to having sane upgrade 
paths and not depend on such kernel features prematurely.

<-- snip  -->


The answer in the systemd position statement says:

<--  snip  -->

... Compatibility at upgrade time should not be a concern either, since 
the real outside interfaces (D-Bus, unit files, Debian configuration 
files) have always been stable (forward compatible) and will remain so. 
There will, most probably, be locked-in upgrades with udev from time to 
time, but it does not have any impact on the ability to upgrade systems.

<--  snip  -->


Can you give a pointer to what guarantees systemd upstream makes 
regarding supporting older kernels?


One example:

Assume kdbus gets merged into the upstream kernel after the kernel that 
ships with jessie.

Would it be guaranteed that the systemd in jessie+1 will still be able 
to work with the jessie kernel, or is there even the slightest risk that 
systemd upstream might at some point make kdbus a mandatory requirement?


And with systemd absorbing functionality like module loading I could 
even imagine nightmare scenarios where additionally the jessie+1 kernel 
would only work with a jessie+1 systemd.


Please clarify whether there is just a pointer to a statement from 
systemd upstream missing, or whether the statement "Compatibility at 
upgrade time should not be a concern either" is incorrect.


Thanks in advance
Adrian

[1] https://wiki.debian.org/Debate/initsystem/systemd
[2] https://wiki.debian.org/Debate/initsystem/upstart

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Message #956 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: Adrian Bunk <bunk@stusta.de>

Cc: 727708@bugs.debian.org

Subject: Re: systemd jessie -> jessie+1 upgrade problems

Date: Tue, 17 Dec 2013 12:38:50 +0100

Hi Adrian,

Le lundi 16 décembre 2013 à 17:52 +0200, Adrian Bunk a écrit : 
> Can you give a pointer to what guarantees systemd upstream makes 
> regarding supporting older kernels?

Systemd is a userspace program. As such, it can has the same problems as
any other userspace programs. A notable similar example is eglibc: some
features require a newer kernel, and fallback code is needed when the
kernel is not recent enough.

So it really boils down to the time that passes between the integration
of a feature to the kernel and its use in systemd. For example, systemd
has a hard dependency on cgroups, but this feature has been in the
kernel from some time.

Problematic examples will not be frequent, and you are right to quote
kdbus as one of them.

> Assume kdbus gets merged into the upstream kernel after the kernel that 
> ships with jessie.
> 
> Would it be guaranteed that the systemd in jessie+1 will still be able 
> to work with the jessie kernel, or is there even the slightest risk that 
> systemd upstream might at some point make kdbus a mandatory requirement?

Upstream systemd will probably make kdbus a requirement:
http://lists.freedesktop.org/archives/systemd-devel/2013-March/009797.html

At this point, if the kernel in jessie does not support kdbus already,
we have several alternatives I can think of: 
     1. Maintain a code path to detect whether kdbus is available and
        fall back to dbus-daemon in this case (better if we can convince
        upstream to integrate the change) 
     2. Make a kdbus DKMS package and make it a dependency for systemd 
     3. Include kdbus in the jessie kernel in a point release 
     4. As a last resort, entirely disable kdbus in jessie+1

Note that if kdbus is adopted, we will need it regardless in glib2.0 and
libdbus. If we do not adopt systemd, we will have to make similar plans
of our own to provide a kdbus-enabled system bus and use it if the
kernel is recent enough. So this problem will exist, with the same
categories of solutions, even if we don’t switch to systemd.

> And with systemd absorbing functionality like module loading I could 
> even imagine nightmare scenarios where additionally the jessie+1 kernel 
> would only work with a jessie+1 systemd.

This would definitely be considered a bug in the kernel.

> Please clarify whether there is just a pointer to a statement from 
> systemd upstream missing, or whether the statement "Compatibility at 
> upgrade time should not be a concern either" is incorrect.

Maybe this was wrongly phrased: of course we should be concerned by
compatibility at upgrade time. But using systemd doesn’t cause more
compatibility problems than those we already have (e.g. with udev).

Cheers,
-- 
 .''`.        Josselin Mouette
: :' :
`. `'
  `-

Message #961 received at 727708@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@stusta.de>

To: Josselin Mouette <joss@debian.org>

Cc: 727708@bugs.debian.org

Subject: Re: systemd jessie -> jessie+1 upgrade problems

Date: Tue, 17 Dec 2013 15:26:19 +0200