[davidstrauss]

Directly talking to the notify socket is not considered using systemd internals. It is documented as a stable, public interface:

https://wiki.freedesktop.org/www/Software/systemd/InterfaceS...

Socket activation doesn't have any systemd-based interface. You just get a file descriptor passed in the normal Unix way. The systemd library functions related to socket activation are utility functions for examining the inherited socket, but they are just wrappers for any other way you might do so.

You can configure daemons like nginx or PHP-FPM to use sockets inherited from systemd instead of their own, and it works fine. They don't have any specific support for systemd socket activation, nor do they need to. They can't even tell the difference between the systemd sockets and ones they'd get on a configuration reload.

[simoncion]

> 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]

The 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