Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support for systemd readiness notification mechanism #310

Open
q66 opened this issue Apr 2, 2024 · 2 comments · May be fixed by #401
Open

support for systemd readiness notification mechanism #310

q66 opened this issue Apr 2, 2024 · 2 comments · May be fixed by #401
Labels
C-dinit Things about the main parts of dinit Feature Request Request a feature to be added to dinit

Comments

@q66
Copy link
Contributor

q66 commented Apr 2, 2024

We have support for s6-style readiness notification with the pipe/file descriptor. It would be nice to additionally have support for systemd-style readiness notification, at very least for its READY state and perhaps a few others that fit (ignoring the rest). This could be accomplished with something like ready-notification = socket or similar.

The mechanism is fairly simple and generic, and would allow seamless support for everything that already implements systemd readiness notification. It's also somewhat more flexible in terms of what can do the notification; since you only need a socket address (carried in through the NOTIFY_SOCKET environment variable), it can be easily passed down to children and the likes, without having to worry about keeping track of an open file descriptor.

@mobin-2008 mobin-2008 added C-dinit Things about the main parts of dinit Feature Request Request a feature to be added to dinit labels Apr 2, 2024
@capezotte
Copy link
Contributor

capezotte commented Jun 15, 2024

Would this feature be restricted to a subset of the platforms, or should we try to make it for all POSIX OSes?

Since (afaik) only Linux attaches credentials to SOCK_DGRAM messages, ¹ on other platforms this would imply multiple sockets (possibly with different permissions each if we want to prevent services from impersonating one another).

Besides, the "readiness notification" mechanism has already expanded the scope to fd-holding too, and there's no way to negotiate the supported feature set or to return errors for these calls other than to close the socket since it's one way from the service to the init system.

If we take the "close the socket after getting READY=1" route, we might as well implement something like dbus-wait-for/s6-notifyoncheck that binds a self-cleaning (abstract) socket, receives and authenticates the message, and exits.

¹See https://github.com/InitWare/InitWare/blob/bcb4aa2d894101b49f142aca0d7941930b5841fa/lib/basic/socket-util.h#L36

@netbsduser
Copy link

Since (afaik) only Linux attaches credentials to SOCK_DGRAM messages, on other platforms this would imply multiple sockets (possibly with different permissions each if we want to prevent services from impersonating one another).

Credential passing over datagram sockets is also available on NetBSD, FreeBSD, and DragonFly BSD. OpenBSD does not though some patches, not accepted, seem to have been sent to them to implement it. I am not aware that macOS or Solaris support it, I don't think they do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-dinit Things about the main parts of dinit Feature Request Request a feature to be added to dinit
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants