The new popular systenmd init system has support for socket activation.
This method of starting daemons is extremely appealing as it allows automatic ordering of operations (the daemon is started right at the moment is needed).
It also allow the daemon to automatically turn itself off after an idel period and save resources. The init system will restart the daemon when needed.
GSS-Proxy is a stateless service so it is particularly well suited to perform wee in this mode of operation.
Metadata Update from @simo: - Issue assigned to simo - Issue set to the milestone: X - DEFERRED
Any progress on this request?
For documentation see http://0pointer.de/blog/projects/socket-activation.html and https://www.freedesktop.org/software/systemd/man/systemd.socket.html
Not that I'm aware of. If you have a particular use case, you're welcome to share it here.
I do have a concern that needs more investigation. Many systems in the wild - especially in clouds - are misconfigured and lack proper entropy (e.g., /dev/urandom passthrough for libvirt). Right now this means that these systems time out in booting, which is admittedly not great but it does make the problem clear. (systemd doesn't appear to have interest in adding a "RNG is fully seeded" dependency, so this isn't going to get better.)
So if we go socket-activated, we may just silently hang the request (or time it out, which would be worse because it would yield unexpected fallback behavior). But on the other hand, krb5 may do enough setup before calling into the interposer that the application would need a fully seeded RNG before hitting the gssproxy socket. This probably requires some testing.
Finally, introducing a hard systemd dependency is an automatic reject from me - using advanced features from systemd is fine, but we need to have fallback.
Metadata Update from @rharwood: - Issue close_status updated to: None - Issue priority set to: None (was: 4)
Project has moved please reopen here if still an issue: https://github.com/gssapi/gssproxy/issues
Metadata Update from @simo: - Issue close_status updated to: Deferred - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.