On 6/8/2015 10:44 AM, Steve Litt wrote:
> Just so we're all on the same page, am I correct that the subject of
> your response here is *not* "socket activation", the awesome and
> wonderful feature of systemd.
>
> You're simply talking about a service opening its socket before it's
> ready to exchange information, right?
That is my understanding, yes. We are discussing using UCSPI to hold a
socket for clients to connect to, then launching the service and
connecting the socket on demand; as a by-product the assumption is the
client will block while the launch is occuring for the socket. Of
course, to make this work, there is an implicit assumption that the
launch includes handling of "service is up" vs "service is ready".
> Isn't this all controlled by the service? sshd decides when to open its
> socket: The admin has nothing to do with it.
UCSPI is basically the inetd concept re-done daemontools style. It can
be a local socket, a network socket, etc. So the UCSPI program would
create and hold the socket; upon connection, the service spawns.
>
>
> [Snip 2 paragraphs discussing the complexity of sockets used in a
> certain context]
>
>> If I were to write support for sockets in, I would guess that it
>> would probably augment the existing ./needs approach by checking for
>> a socket first (when the feature is enabled), and then failing to
>> find one proceed to peer-level dependency management (when it is
>> enabled).
> Maaaaannnnn, is all this bo-ha-ha about dependencies?
Sequencing actually; I'm just mixing a metaphor here, in that "my
version" of dependencies is sequential, self-organizing, but not
manually ordered. Order is obtained by sequentially walking the tree,
so while you have a little control by organizing the relationships, you
don't have any control over which relationship launches first at a given
level.
>
> =====================================
> if /usr/local/bin/networkisdown; then
> sleep 5
> exit 1
> fi
> exec /usr/sbin/sshd -d -q
> =====================================
>
> Is this all about using the existance of a socket to decide whether to
> exec your service or not? If it is, personally I think it's too
> generic, for the reasons you said: On an arbitrary service,
> perhaps written by a genius, perhaps written by a poodle, having a
> socket running is no proof of anything. I know you're trying to write
> generic run scripts, but at some point, especially with dependencies on
> specific but arbitrary processes, you need to know about how the
> process works and about the specific environment in which it's working.
> And it's not all that difficult, if you allow a human to do it. I think
> that such edge case dependencies are much easier for humans to do than
> for algorithms to do.
Oh, don't get me wrong, I'm saying that the human should not only be
involved but also have a choice. Yes, I will have explicit assumptions
about "X needs Y" but there's still a human around that can decide if
they want to flip the switch "on" to get that behavior.
>
> If this really is about recognizing when a process is fully functional,
> because the process being spawned depends on it, I'd start collecting a
> bunch of best-practices, portable scripts called ServiceXIsDown and
> ServiceXIsUp.
This is of passing interest to me, because a lot of that accumulated
knowledge can be re-implemented to support run scripts. I may write
about that separately in a little bit.
> Sorry for the DP101 shellscript grammar: Shellscripts are a second
> language for me.
The project is currently written in shell, so you're in good company.
>
> Anyway, each possible dependent program could have one or more
> best-practice "is it up" type test shellscripts. Some would involve
> sockets, some wouldn't. I don't think this is something you can code
> into the actual process manager, without a kudzu field of if statements.
It wouldn't be any more difficult than the existing peer code. Yes, I
know you peeked at that once and found it a bit baroque but if you take
the time to walk through it, it's not all that bad, and I'm trying hard
to make sure each line is clear about its intention and use.
Regarding an older comment that was made about relocating peer
dependencies into a separate script, I'm about 80% convinced to do it,
if only to make things a little more modular internally.
>
> [snip a couple paragraphs that were way above my head]
>
>> Of course, there are no immediate plans to support UCSPI, although
>> I've already made the mistake of baking in some support with a bcron
>> definition. I think I need to go back and revisit that entry...
> I'm a big fan of parsimonious scope and parsimonious dependencies, so
> IMHO the less that's baked in, the better.
The minimum dependencies are there. If anything, my dependencies are
probably lighter than most - there isn't anything in shell that is baked
in (i.e. explicit service X start statements in the script outright),
and the dependencies themselves are simply symlinks that can be changed.
>
>> 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.
> Avery, I'm nowhere near your knowledge level on init systems, but I've
> wondered that myself. A 2 second boot would be nice, but at what cost?
For that matter, if there is a requirement to boot in less than 2
seconds, you're (a) probably doing something wrong, as redundant
services/servers elsewhere can be used or (b) have a special edge case,
such as embedded hardware on an orbital space station, where the next
"service call" costs several million dollars and is planned in terms of
months. Both situations are well beyond normal.
> Plus there's this: Even original daemontools is nowhere near serial:
> Correct me if I'm wrong, but I believe that with daemontools, svscan
> keeps spinning, testing and trying, while supervise modules are
> instantiating their daemons.
Correct, that is my understanding as well.
>
> Sometimes, in my more cynical moods, I wonder whether "parallel
> instantiation" is less of a helpful feature than it is a marketing
> bulletpoint, much like "magnesium paddle shifter."
>
"Shiny paddle shifters, for great win."
Received on Mon Jun 08 2015 - 18:57:24 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:19 UTC