Bug#727708: init system other points, and conclusion [and 1 more messages]
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 ?
That systemd support SIGSTOP readiness indication; that it support a
different simpler readiness protocol; or that it allow relative
pathnames in unit files ?
Of these your objection clearly doesn't apply to the first two.
systemd already supports around four readiness signally protocols
(depending how count them); adding another would certainly not break
anything.
The last one - relative pathnames - is a strict enhancement. The
only effect would be that Debian's unit files wouldn't necessarily
work on older systemds which didn't have the patch.
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.
Lennart writes:
| sending a message to $NOTIFY_SOCKET would require setting
| SCM_CREDENTIALS (wrong!),
But the only documentaton I can find for this protocol is in
sd_notify(3), which says[1]:
| The datagram is accompanied by the process
| credentials of the sending daemon, using SCM_CREDENTIALS.
If this is not required by systemd, why is it done by sd_notify ?
Is this actually the right documentation to be reading ?
Ian.
[1] http://manpages.debian.net/cgi-bin/man.cgi?query=sd_notify&sektion=3&apropos=0&manpath=Debian+testing+jessie&locale=
Reply to: