njsmith
commented
7 years ago Systemd check-list for well-behaved Linux daemons: https://www.freedesktop.org/software/systemd/man/daemon.html#New-Style%20Daemons (scroll-up for a checklist for old-style daemons)
(See also: suggestions for writing daemons that accept sockets from systemd or fall back to creating their own)
MacOS documentation for well-behaved MacOS daemons: https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html
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 #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 #251 – while systemd prefers to use introspection and only supports names as a fallback.)
graceful shutdown -- SIGTERM, however windows services do it