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

[Alexander Kjeldaas]

I'll just jump in and say that if you is going to donate time to do this,
Ertugrul, then I'm all for it.

It seems like it is possible to make the service system a lot leaner,
smaller, and nicer.  This is especially true when services are in
containers, or NixOS is used in docker containers.

For those that don't really get what Ertugrul describes, looking at what is
called "orchestration systems" for docker gives a sense of what I think he
is talking about. An orchestration system is a way of defining how multiple
docker containers are connected to each other.

The orchestration system itself doesn't necessarily need to "keep" the
state of the system, because the cloud system it operates on can just spin
up new instances, or the cloud system has a service discovery mechanism, or
which service is active is handled by a load balancer.

Similarly, on a host, when we have cgroups/containers/namespaces, we can
spin up a new service in a container and redirect traffic to it by fiddling
with namespaces, routing settings etc.  We can make

I am mostly interested in seeing how the monoid

On Sat, Dec 27, 2014 at 6:53 PM, Ertugrul Söylemez <ertesx at gmx.de> wrote:

> Hi there Tobias,
>
> >> One thing most of us seem to agree about [...]
> >
> > Maybe that's true (I don't see a consensus on the list, only the usual
> > sparse FUD. I don't follow IRC) but arguments that start this way
> > always give me the willies.
>
> I understand why, but I'm not very good at English rhetoric.  Please
> don't let that overshadow the rest of the mail.
>
>
> >> [...] is that conceptually NixOS does not depend as much on something
> >> like systemd as most other distributions do.
> >
> > "Something like systemd"? Nix doesn't magically make *nix less *nix,
> > for better or worse. The meat of systemd is still service management,
> > which NixOS needs as much as any distribution.
>
> NixOS needs service *management*, but it doesn't necessarily need a
> service *manager*.  In traditional distributions services are managed by
> destructive update (enable/disable).  Normally we don't have that.
>
>
> >> Switching to it was a huge step back from the ideals of NixOS,
> >> because it represents all the traditional views on what a system
> >> should look like: a giant pile of interconnected mutable variables.
> >
> > That's what a running system is, though. Immutability *is* just for
> > file systems. You plant a pretty tree, and hope it describes a sane
> > system that will do the right thing most of the time. Then, something
> > will happen that will kick all your pretty algebraic assumptions off
> > the table very quickly. Most of your OS is in buggy C, whether you
> > like it or not...
>
> The assumptions are not that the programs will do what I expect them to
> do, but rather that "two instances of nginx each with one virtual host"
> is equivalent "one instance of nginx with two virtual hosts".  This does
> not assume anything about the correctness of nginx itself, but it does
> help building systems, containers and networks componentwise.
>
>
> > You seem to have some very nice ideas about describing "services" (or
> > something better), if still very rough around the edges. But if you
> > can't implement your ideas on top of systemd, so much for
> > init-agnosticism. And probably conceptual purity, too.
>
> This may be a misunderstanding.  Init-agnosticism means that the
> complexity of translating this concept to an actual set of services that
> systemd can work with is the responsibility of a single
> function/script/whatever.  We achieve separation of concerns.
>
> Should we, at any point, decide to turn our back on systemd or even just
> provide the option to use another manager, then all we need to do is to
> reimplement this one function/script/whatever.
>
>
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 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.

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).

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.  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.

Alexander


>
> > Those who don't understand systemd are doomed to reinvent
> > it. Poorly. :-)
>
> I do understand systemd very well and still don't like it.  However,
> reinventing it is certainly not something I have planned for the near
> future. =)
>
>
> >> As a final bonus this is so difficult and ugly to solve with systemd
> >> that we would feel a much greater temptation to get rid of it. =)
> >
> > Because your plan is centred entirely around it not being systemd.
>
> Not at all.  It would be a nice bonus, but I doubt that it's going to
> happen.  The motivation for my proposal, as the motivation for most of
> the things I do right now, is easy, composable, transparent
> containerisation as well as a configuration DSL that is easy to reason
> about.
>
>
> Greets,
> Ertugrul
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20141228/3f779faa/attachment.html