Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Russ Allbery]

Uoti Urpala  writes:

> BTW it's worth noting that in the typical daemon case where "readiness"
> means the listening socket is ready to accept requests, the right way to
> convert the daemon to a new API is to use socket activation, which
> removes the need for separate start-up completion notification. Thus the
> need to use sd_notify() for this purpose should be the exception rather
> than the rule. This means that daemons which would use libsystemd-daemon
> for startup notification and nothing else (and would thus be potential
> candidates to abuse SIGSTOP) should be rare.

Good point.  Anything that's using socket activation probably doesn't
really need additional synchronization.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ppopua6g@windlord.stanford.edu

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Uoti Urpala]

On Sat, 2013-12-21 at 08:49 -0800, Russ Allbery wrote:
> Tollef Fog Heen  writes:
> > sd-daemon.c is also intentionally designed to not have dependencies on
> > the rest of the systemd source and to be portable to non-linux
> > architectures too (but basically just stubs then) just so people can put
> > the file in their source and not have to fiddle with checking for
> > libraries and such if they find that tedious.
> 
> I agree with Ian's dislike of this approach.  We try to avoid embedded
> code copies, and I'm not sure why this would be an exception.  Yes, the
> code is fairly simple and hopefully doesn't contain (for example) security
> vulnerabilities, but it's possible to find bugs in just about anything.
> Updating numerous copies of that code is not appealing.

I don't see why that should be considered a particularly significant
downside though. Copies are usually worse than shared code, but not
really worse than everything having a custom implementation. At least
implementing sd_notify() support with a code copy should be considered a
significant improvement over a daemon that always runs custom
double-forking code.

BTW it's worth noting that in the typical daemon case where "readiness"
means the listening socket is ready to accept requests, the right way to
convert the daemon to a new API is to use socket activation, which
removes the need for separate start-up completion notification. Thus the
need to use sd_notify() for this purpose should be the exception rather
than the rule. This means that daemons which would use libsystemd-daemon
for startup notification and nothing else (and would thus be potential
candidates to abuse SIGSTOP) should be rare.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1387662984.3938.143.camel@glyph.nonexistent.invalid

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Tollef Fog Heen]

]] Russ Allbery 

> Tollef Fog Heen  writes:
> 
> > sd-daemon.c is also intentionally designed to not have dependencies on
> > the rest of the systemd source and to be portable to non-linux
> > architectures too (but basically just stubs then) just so people can put
> > the file in their source and not have to fiddle with checking for
> > libraries and such if they find that tedious.
> 
> I agree with Ian's dislike of this approach.  We try to avoid embedded
> code copies, and I'm not sure why this would be an exception.  Yes, the
> code is fairly simple and hopefully doesn't contain (for example) security
> vulnerabilities, but it's possible to find bugs in just about anything.

Sure.  There's a tradeoff as always.  I wanted to point out that
embedding it is intentionally easy.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m2vbyihqq8@rahvafeir.err.no

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Russ Allbery]

Tollef Fog Heen  writes:

> sd-daemon.c is also intentionally designed to not have dependencies on
> the rest of the systemd source and to be portable to non-linux
> architectures too (but basically just stubs then) just so people can put
> the file in their source and not have to fiddle with checking for
> libraries and such if they find that tedious.

I agree with Ian's dislike of this approach.  We try to avoid embedded
code copies, and I'm not sure why this would be an exception.  Yes, the
code is fairly simple and hopefully doesn't contain (for example) security
vulnerabilities, but it's possible to find bugs in just about anything.
Updating numerous copies of that code is not appealing.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8738lmw3m3@windlord.stanford.edu

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Tollef Fog Heen]

]] Russ Allbery 

> Ian Jackson  writes:
> > Russ Allbery writes:
> 
> >> I'd like to see both of them support systemd's method, since it's
> >> extensible and provides more general functionality.  I think the
> >> benefit of support for SIGSTOP is marginal; adding sd_notify calls is
> >> not that much harder and doesn't have the conceptual weirdness of
> >> stopping the daemon to notify the init system that it's running.
> 
> > I strongly disagreee.
> 
> > As the upstream author of a daemon I'm
> >  - not willing to add a library dependency for this
> >  - not willing to write a 50-100 lines of tiresome socket code for this
> >  - not willing to copy the library file into my source tree
> > so the result is that userv upstream won't support systemd's readiness
> > protocol.
>
> Yes, we completely disagree.
> 
> Among other things, that's about the smallest and least-impactful library
> dependency I can imagine.

sd-daemon.c is also intentionally designed to not have dependencies on
the rest of the systemd source and to be portable to non-linux
architectures too (but basically just stubs then) just so people can put
the file in their source and not have to fiddle with checking for
libraries and such if they find that tedious.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txe2xt2j@xoog.err.no

Bug#727708: systemd as cgroup writer

[Josselin Mouette]

Hi Andreas,

Le samedi 21 décembre 2013 à 08:48 +0100, Andreas Barth a écrit : 
> 1. Does systemd (or a part of the systemd project) need to be the
> single cgroup writer and if so, why?

It does not… so far. The only thing currently required is for cgroups
consumers to adhere to the shared guidelines¹ different projects agreed
upon. As of today, there is no impact for us.

What is changing is that the kernel cgroups developers want to fix the
current mess cgroupfs has become². The identified solution is to only
allow one cgroupfs hierarchy to be mounted and to let it be managed only
by one process. The future kernel API has not been completely stabilized
yet, but that much is clear.

If you use systemd, this cgroups arbitrator has to lie in systemd
itself. This is because systemd already starts all services as part of
cgroups from PID 1. Otherwise, you can use another arbitrator such as
cgmanager. Both have chosen the approach to provide the cgroups
functionality as a D-Bus API to cgroups consumers (which makes a lot of
sense).

As I understand the transition plan, it goes this way: 
 1. Migrate cgroups consumers to a D-Bus API instead of using
cgroupfs directly. 
 2. Stabilize the new kernel API and start providing it in the
kernel. 
 3. On a switch day, the cgroups arbitrator starts mounting cgroupfs
with the new API. Consumers still accessing the old API stop
working. 
 4. The old kernel API is deprecated and eventually removed in the
distant future.

Systemd developers are getting ready to part 3 by working closely with
the kernel cgroups developers. It is not clear to me whether cgmanager
will be able to do the same: from my discussions with more knowledgeable
people, it is merely exposing the current cgroups API in D-Bus calls.
This approach cannot work transparently when the API changes. Therefore,
we might only have one available cgroups arbitrator in the end: systemd.


 ① http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups/
 ② 
http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linux-kernel-cgroup%E2%80%99s-redesign


> 2. What problems do arise from there for other parts of the linux
> ecosystem?

These other parts have to migrate to a D-Bus-based interface. The
problem is that systemd and cgmanager developers have not been able so
far to agree on a common API. The consequences for those
cgroups-consuming services are easy to infer. 
  * Some services will only support systemd. 
  * Some will use more complex code in order to support both. 
  * Some will wait until a “standard” emerges and will not work
towards the transition. 

With the systemd API being already available³ and part of the stability
promise⁴, the only way this can happen is for cgmanager to start
providing a systemd-compatible API, which in turn is unlikely since
these are just extensions to the base API controlling systemd itself.

Expect Red Hat, Samsung or Intel to provide patches if one of their
products includes a relevant package. I think this is already the case
for libvirt and LXC.


 ③ http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
 ④ 
http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/


Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1387628136.24917.40.camel@tomoyo