>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
Received on Wed Apr 01 2020 - 15:59:25 UTC