You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A very common use case for a library like trio is writing long-running server processes. We should make it easy to get this right. This should probably be as a new package on top of trio. Some brainstorming:
Integrating with platform-specific service management systems:
Windows services
Launchd integration, in particular socket activation. This is done by calling launch_activate_socket("lookup-key", ...), which returns an array of fds. (Could be multiple e.g. one for IPv4 and one for IPv6).
Systemd integration: socket activation (depends on On Linux, set up socket object correctly when creating from an fd #251), watchdog support, sd_notify, maybe sd_pid_notify_with_fds, ... (see sd-daemon.h). These can be done via a binding to libsystemd or through our own implementation (they're all pretty trivially defined in terms of environment variable manipulation etc.), and either way there's a choice whether to write our own or use an existing one.
It might also make sense to support classic double-fork daemonization, though that's fallen out of popularity these days.
Generic services:
abstracting away the differences between different socket activation styles (a bit tricky, since launchd always uses names but we can't really introspect the returned sockets – again see On Linux, set up socket object correctly when creating from an fd #251 – while systemd prefers to use introspection and only supports names as a fallback.)
graceful shutdown -- SIGTERM, however windows services do it
The text was updated successfully, but these errors were encountered:
That MacOS docs page says that daemons should "check in" (which according to the sample code uses launch_msg) and get the "launch dictionary", but I guess actually this is deprecated?
A very common use case for a library like trio is writing long-running server processes. We should make it easy to get this right. This should probably be as a new package on top of trio. Some brainstorming:
Integrating with platform-specific service management systems:
Windows services
Launchd integration, in particular socket activation. This is done by calling
launch_activate_socket("lookup-key", ...)
, which returns an array of fds. (Could be multiple e.g. one for IPv4 and one for IPv6).Systemd integration: socket activation (depends on On Linux, set up socket object correctly when creating from an fd #251), watchdog support,
sd_notify
, maybesd_pid_notify_with_fds
, ... (see sd-daemon.h). These can be done via a binding to libsystemd or through our own implementation (they're all pretty trivially defined in terms of environment variable manipulation etc.), and either way there's a choice whether to write our own or use an existing one.It might also make sense to support classic double-fork daemonization, though that's fallen out of popularity these days.
Generic services:
abstracting away the differences between different socket activation styles (a bit tricky, since launchd always uses names but we can't really introspect the returned sockets – again see On Linux, set up socket object correctly when creating from an fd #251 – while systemd prefers to use introspection and only supports names as a fallback.)
graceful shutdown -- SIGTERM, however windows services do it
The text was updated successfully, but these errors were encountered: