On 08/06/2015 16:00, Avery Payne wrote:
> This is where I've resisted using sockets. Not because they are bad
> - they are not. I've resisted because they are difficult to make
> 100% portable between environments. Let me explain.
I have trouble understanding several points of your message.
- You've resisted using sockets. What does that mean ? A daemon
will, or will not, use a socket; as an integrator, you don't have
much say on the matter. You can decide where the socket will be,
what will open it, how the daemon will get it if it doesn't open
it itself, and other similar details; but you cannot, say, write
a run script for a X11 server if you don't want any Unix domain
sockets on the machine. :) So, can you clarify your resistance ?
- What tools are available. What does that have to do with
daemons using sockets ? UCSPI tools will, or will not, be available,
but daemons will do as they please. If your scripts rely on UCSPI
tools to ease socket management, then add a package dependency -
your scripts need UCSPI tools installed, end of story. Dependencies
are not a bad thing per se, they just need to be controlled and
justified.
"UCSPI sockets" does not make sense. You'll have Unix sockets and
INET sockets, and maybe one or two esoteric things such as netlink.
UCSPI is a framework that helps manipulate sockets with command-line
utilities. Use the tools or don't use them, but I don't understand
what your actual problem is.
> So where do
> the sockets live? /var/run? /run? /var/sockets?
> /insert-my-own-flavor-here?
How about the service directory of the daemon using the socket ?
That's what a service directory is for.
> * Make socket activate an admin-controlled feature that is disabled
> by default. You want socket activation, you ask for it first. The
> admin gets control, I get more headache, and mostly everyone can be
> happy.
If all this fuss is about socket activation, then you can simply
forget it altogether. Jonathan was simply mentioning socket activation
as an alternative to real dependency management, as in "that's what
some people do". I don't think he implied it was a good idea. Only
Lennart says it's a good idea. Or people who blindly repeat what
Lennart says.
> As a side note, I'm beginning to suspect that the desire for "true
> parallel startup" is more of a "mirage caused by desire" rather than
> by design. What I'm saying is that it may be more of an ideal we
> aspire to rather than a design that was thought through. If you have
> sequenced dependencies, can you truly gain a lot of time by
> attempting parallel startup? Is the gain for the effort really that
> important? Can we even speed things up when fsck is deemed mandatory
> by the admin for a given situation? Questions like these make me
> wonder if this is really a feasible feature at all.
It's feasible. Anopa does it. s6-rc does it too - there are still a lot
of things missing so I can't release it now, but the core functionality
is done and it works.
At least, if by "parallel startup" you mean "start things as soon as
they can be started without risk, without needless waiting times".
Because if you want "parallel startup" as in "start all the things
and pray it works", you can already do it today, with any supervision
framework (services will restart until their dependencies are met)
or with systemd (socket activation: everything will be fine unless
something important crashes, in which case we will deny there is a
problem).
What I don't think is feasible is having an easy way of accomplishing
parallel startup without a real service management tool specifically
thought out and designed to handle dependencies properly, and
especially mixing one-shot services and long-run services. Which is
exactly what anopa and s6-rc do.
--
Laurent
Received on Mon Jun 08 2015 - 18:55:16 UTC