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
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.
-
Laurent Bercot wrote:
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
On 08/06/2015 22:40, Jonathan de Boyne Pollard wrote:
As to whether opening server sockets early is a good idea: I'm not in
a hurry to naysay. It achieves the stated effect. Arguably, indeed,
it can be described as *what the system already does* if one has a
lot of daemontools-style services
On Mon, 08 Jun 2015 21:08:38 +0100
Jonathan de Boyne Pollard j.deboynepollard-newsgro...@ntlworld.com
wrote:
The systemd dictum is that to truly take advantage of parallel
startup, one eliminates orderings as far as possible. Which is where
socket activation comes in. Part of socket
On 6/8/2015 2:15 PM, Steve Litt wrote:
I'm not familiar with inetd. Using sockets to activate what? In what
manner? Whose socket?
~ ~ ~
Let's go back in time a little bit. The year is 1996, I'm downstairs
literally in my basement with my creaky old 486 with 16Mb of RAM and I'm
trying to
On 5/14/2015 3:25 PM, Jonathan de Boyne Pollard wrote:
The most widespread general purpose practice for breaking (i.e.
avoiding) this kind of ordering is of course opening server sockets
early. Client and server then don't need to be so strongly ordered.
This is where I've resisted using
Buck Evan:
For example, I'd like to encode the fact that I don't expect service A to be
able to come up before service B.
In nosh, the filesystem is the database. This is an ordering, not a
dependency. One can separately encode in nosh (a) that start of service
B will cause the start of
On 4/21/2015 2:19 PM, Buck Evan wrote:
Does s6 (or friends) have first-class support for dependant services?
I know that runit and daemontools do not. I do know that nosh has
direct support for this. I believe s6 supports it through various
intermediary tools, i.e. using socket activation to
On 4/21/2015 2:56 PM, Buck Evan wrote:
My understanding of s6 socket activation is that services should open,
hold onto their listening socket when they're up, and s6 relies on the
OS for swapping out inactive services. It's not socket activation in
the usual sense.
On 4/21/2015 3:08 PM, Buck Evan wrote:
On Tue, Apr 21, 2015 at 2:46 PM, Avery Payne avery.p.pa...@gmail.com
mailto:avery.p.pa...@gmail.com wrote:
Alternatively, are there general-purpose practices for
breaking this kind
of dependency?
Strange as it sounds,
My understanding of s6 socket activation is that services should open, hold
onto their listening socket when they're up, and s6 relies on the OS for
swapping out inactive services. It's not socket activation in the usual
sense. http://skarnet.org/software/s6/socket-activation.html
So I wonder
12 matches
Mail list logo
