Bug#727708: init system other points, and conclusion [and 1 more messages]

[Tollef Fog Heen <tfheen@err.no>]

]] Ian Jackson 

> Tollef Fog Heen writes ("Bug#727708: init system other points, and conclusion"):
> > Ian Jackson:
> > > This is exacerbated by the fact that systemd's Debian maintainers are
> > > (IMO) much too deferential to upstream.
> > 
> > That's because the bits of systemd you've asked to change isn't just a
> > piece of software.  It's a standardised API, and you're effectively
> > asking us to change that API.  I think it's pretty clear why that is a
> > bad idea.
> 
> Which of my three rejected proposals are you discussing ?

All of them.  It means that you can't test and verify that a daemon
works correctly with systemd in Debian and expect it to work the same
with systemd in other distributions.

I'm not saying those kinds of changes are unwanted.  I'm saying they
should go upstream and that I am unwilling to carry those patches in the
Debian package.

> Tollef Fog Heen writes ("Bug#733452: init system daemon readiness protocol"):
> > It seems Lennart read the proposal and responded in
> > https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/37AWJLE3XcJ
> 
> In the light of this message from Lennart, and the example code, it
> seems that the documentation is not adequate.

I think you're just being confused by it giving you some information you
don't need.  The documentation in question reads: 

  Internally, these functions send a single datagram with the state
  string as payload to the AF_UNIX socket referenced in the
  $NOTIFY_SOCKET environment variable. If the first character of
  $NOTIFY_SOCKET is «@», the string is understood as Linux abstract
  namespace socket. The datagram is accompanied by the process
  credentials of the sending daemon, using SCM_CREDENTIALS.

  For details about the algorithms check the liberally licensed
  reference implementation sources:
  http://cgit.freedesktop.org/systemd/systemd/plain/src/libsystemd-daemon/sd-daemon.c
  and
  http://cgit.freedesktop.org/systemd/systemd/plain/src/systemd/sd-daemon.h

SCM_CREDENTIALS is generally not something the sender sends, it's
something the receiver sets on the socket using SO_PASSCRED.

> If this is not required by systemd, why is it done by sd_notify ?

It's not.

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