RE: s6 init-stage1

From: James Powell <>
Date: Tue, 6 Jan 2015 12:51:03 -0800

The problem of using sockets rather than named pipes is that each UNIX socket requires more POSIX shared memory increasing the system resource base requirements. Named pipes just use normal process memory which keeps system requirements less. How Lennart failed to mention that in the systemd presentation is insane.

Sent from my Windows Phone
From: post-sysv<>
Sent: ‎1/‎6/‎2015 12:03 PM
To: Laurent Bercot<>
Subject: Re: s6 init-stage1

On 01/06/2015 07:48 AM, Laurent Bercot wrote:
> Interesting. Thanks for the heads-up - I had heard of tsort, but didn't
> know exactly what it does.
> However, I'd like a tool that knows what steps it can parallelize.
> A sequential output is great for functions name in a piece of code,
> but for services, the point is to start as many as possible in
> parallel, and minimize the amount of synchronization points.
> For instance, given
> 1 2
> 3 4
> meaning 2 should happen after 1, and 4 should happen after 3,
> tsort gives
> 1
> 3
> 2
> 4
> but instead, I need something like
> 1 3
> 2 4
> because 1 and 3 can happen in parallel, and same for 2 and 4.
> AFAICT, tsort cannot do that. (make might not be able to either,
> but since it's more complex, it's harder to tell.)

  About that. Actually, I'm not even certain if there exists a service
manager that
*actually* starts processes in parallel. Usually what I've noticed is
that most of
the time what is really meant is that services are started
asynchronously, or at
best concurrently.

  Debian and other formerly sysvinit-based distributions had what was
known as
a "Makefile-style concurrent boot". To the best of my knowledge, this
was done
using a combination of LSB initscript headers through insserv, and a
called startpar.

  Reading the source code of startpar, I was surprised to see that it
does its job
through a primitive form of socket activation in the run() function
where it allocates
a so-called "preload" socket and determines exit status by its
availability for
connection. Secondary routines including meddling with ptys and file
to curb interleaving and make sure the execution state is clean and free of
potentially blocking operations.

  Makes me wonder if Poettering ever read it, though his ostensible
was from launchd. That said, it does show that the systemd supporters have
overhyped the novelty of "socket activation" (inetd) even more
than I had previously thought. Someone should make note of this.

  In any event, I'm under the impression that most so-called parallel
service starters
are really ones that start asynchronously in a clean execution state, as
parallelism and even concurrency sounds conceptually quite difficult,
when you keep in mind that many boot processes are I/O-bound, primarily.
systemd itself has a complex dependency system at its backbone, with socket
activation not being a mandatory thing from what I've learned. It also
blocks on
occasion to fulfill start jobs, so evidently it has synchronization
methods that are
contrary to its claims.

  If someone can clarify this issue or point to any concurrent/parallel
schemes for
starting services at boot time that have been implemented, that would be
Received on Tue Jan 06 2015 - 20:51:03 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:18 UTC