You'd have to buy into it with a syscall that says "let me know when something listens on tcp port N". In turn s6-supervise would only do that if some config said "don't start service Y until something (which is expected to be service X) proves it's ready by listening on port N". The idea was to handle cases like libvirt being ready to accept VM managing requests.
Yes, so it's not only about adding a pollable fd to a fd set, it's also telling the kernel what kind of notifications you're interested in receiving. So that means: for the supervisor, designing and parsing a config file; for the service writer, writing a supervisor-specific config file. You added complexity to the supervisor, made it more difficult to change supervisors by locking in service config files, added burden to packagers, and turned a two-way transaction into a three-way one (that now includes the kernel). All this to achieve one benefit: make no changes to daemons. It seems very much not worth it. Also, "Don't start service Y until something is ready" is not the supervisor's job, it's the service manager's. The supervisor only reports service readiness; the service manager can make use of it if needed. If your mechanism assumes that the supervisor and the service manager are one and the same program, it enforces a monolithic design - systemd people will love it, but I won't.
Not all of it. But it appears to me the whole world gave into systemd for the sake of socket activation
Yeah, based on propaganda and hype. Doesn't mean it's good tech, and I don't understand the urge to add to the problem.
and in my time handling upstart service dependency for ubuntu server, availability over the network was the most common, perhaps even the only, usable metric.
It's just a question of setting up IPCs. It's only important to know when a service is ready because you want to communicate with that service, so in theory you could exhaustively list all existing IPC mechanisms (of which inet domain sockets would be the most common), and make it work that way. I still don't think it would be a good idea.
Mind you I'm certainly open to the idea that maybe this isn't worth doing - else I'd have actually implemented it by now :) But so far I've not seen anything that seems as good, let alone better.
I'm looking at the total amount and distribution of effort. Adding s6-style readiness notification to an existing daemon is like 4 lines of code, and the effort is trivially distributed, so it's easy. (And running such a daemon under another supervisor is also easy, see sdnotify-wrapper.) Your proposal requires - adding stuff to the kernel: significant effort for kernel devs - forcing supervisors to add config options to support it: significant effort for supervisor devs, and breaks cross-OS portability - forcing distros to add config options to enable it: small amount of effort, easily distributed - the only people it doesn't impact is daemon code maintainers - the kernel is now involved in something that could be handled in a pure userland way with existing mechanisms So, how much has the daemon code maintainers lobby paid you, and how can I get a share of it? :P -- Laurent
