3 ms·
> Directly talking to the notify socket is not considered using systemd internals. Then -according to digi_owl's report- it sounds like the documentation for t
by simoncion 11y ago
> Directly talking to the notify socket is not considered using systemd internals.
Then -according to digi_owl's report- it sounds like the documentation for the signalling lib should be fixed.
- davidstrauss 11y agoThe closest I could find in the docs to what digi_owl said is the following: > 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 service, using SCM_CREDENTIALS. I can see how someone would be reluctant to rely on that, even given the interface promise and the nudging of the systemd developers. To be more consistent with what's a stable, public interface and the admonition to avoid internals, I would probably drop the word "internally." Indeed, I've created a pull request: https://github.com/systemd/systemd/pull/1759 https://github.com/systemd/systemd/pull/1759
- simoncion 11y agoProps for fixing the documentation. :D However, even with your change, I still read that section as describing implementation detail that's not guaranteed to be stable. If that note describes a stable, documented protocol, a link back to the documentation of that protocol would be helpful and reassuring.