[Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))

[Ertugrul Söylemez]

Hi Alexander,

> We can use a monoid system to construct configurations, but the socket
> activation standard for example, is centered on optimizing the
> activation script itself.  What are your thoughts on the activation
> script?

I have no concrete thoughts at this point, just throwing around ideas.
Socket activation, for those daemons that support it, should be
something sufficiently transparent from the point of view of the
configuration author.


> I can easily see that using systemd might be overkill and way too
> complex for a container-based system, so I think there is something to
> research here.

The trouble with systemd for this particular purpose is that it wants
everything to have an identity, so basically you need to map a
compositional system to a system of global variables.  In many ways you
go through the same trouble when compiling a functional language to an
imperative architecture.


> I also think upgrading services doesn't really seem to work in systemd or
> in the current setup.  Similarly to how, when using a distributed docker
> setup, we have a load-balancer that atomically switches instances, we
> should not need to take down the old instance service before the new one is
> created.
>
> Rather, the upgraded service should be started in isolation (using
> containers), and after ensuring that it has started, is working etc, then
> should the switch happen using namespaces, routing entries etc.  This
> should be the preferred way to deal with non-transactional services (i.e.
> non-database stuff).

That's pretty much the way I want upgrading to work.


> The idea that the old service must be stopped before the new one is
> started is based on what I think is a conflation of concerns, namely
> treating the whole service state as global state.

Yes, that's exactly what I want to get rid of.  Ironically that's
something systemd does very well.  Systemd gets the stuff right that we
don't want in the first place. =)


> Instead a lot of services can be treated as a sequence of isolated
> containers, and a small set of "load-balanced", mutable service entry
> points.  Namespace magic can make a lot of previously global state,
> local, such as ports, pid-files, log files etc.
>
> For these kinds of services, you don't need graceful shutdown, which is a
> great simplification, similarly to what docker typically provides.
>
> I feel that a great design in this area should blend well with distributing
> services across machines, failover, etc. which are concerns that systemd
> doesn't start to cover.

That's a very good summary of why I want to implement my proposal.  Let
me see if I can get a working prototype.


Greets,
Ertugrul