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

[Shea Levy]

Hi all,

At Zalora, we are gradually switching to using defnix <https://github.com/zalora/defnix>. It is still very much under active development (read: may change at any time), and the underlying implementation does use systemd, but the service/functionality interface (check out the defnixos directory) are specifically designed to be init system agnostic. In particular, behaviors like socket activation, cron jobs, restart on failure, etc. are all managed via independent programs/library functions that don’t require any specific functionality from the init system. Eventually even “start a bunch of services” will be managed like that as well.

~Shea

> On Dec 27, 2014, at 6:48 AM, Ertugrul Söylemez <ertesx at gmx.de> wrote:
> 
> Hi there Anderson,
> 
>> I want to know if it's possible to use an alternate to Systemd as init
>> system on NixOS.
> 
> this has been asked many times now, and I'm in favour of switching to an
> alternative.  Unfortunately it's not easy, because a considerable
> portion of NixOS currently depends on systemd, most notably the services
> infrastructure and pretty much all container-related stuff.  Note that
> systemd is not just an init system.
> 
> One thing most of us seem to agree about is that conceptually NixOS does
> not depend as much on something like systemd as most other distributions
> do.  In principle most of what systemd does could be handled by the
> activation script and perhaps a custom daemon (or even just a set of
> scripts) that allows us to manage the services that are part of the
> current system derivation.  NixOS can deal with things like cgroups or
> ACPI events in a more sensible, repeatable and transparent way.
> 
> I would go as far as to say that systemd is the number one thing that
> cripples us in many ways.  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.  Remember that immutability is not only about the filesystem.
> 
> 
> How to get rid of systemd
> =========================
> 
> I think as a first step to get rid of systemd and gain a much more
> sensible services model as well we should move away from NixOS modules
> for services.  At this point we are trapped in the traditional view that
> services preexist and we get to enable/disable them.  Our system is
> defined by a large set of switches and global settings.  This needlessly
> robs us of a lot of flexibility, for example to run multiple instances
> of the same daemon or to give us a choice to use our already running
> preferred webserver when installing a web application as a service.
> 
> It also corrupts our ability to reason about the resulting system,
> because enabling a certain service might trigger settings in some other
> part of the system configuration to change.  This has actually bitten me
> in the past.  Being able to reason about the resulting system is very
> important.
> 
> I would prefer and do propose an algebraic solution (view services as a
> toolbox from which you can pick the services you want and compose them
> together).  A services configuration then might look like this:
> 
>    services =
>        bitlbee { port = 10000; stateDir = "/var/lib/bitlbee1"; } <>
>        bitlbee { port = 10001; stateDir = "/var/lib/bitlbee2"; } <>
>        nginx { httpConfig = "..."; } <>
>        postfix { postMasterAlias = "blah"; }
> 
> The big difference is that now services are first class values and form
> a monoid under composition, which brings a number of advantages:
> 
>  * It allows us to run multiple instances of a daemon with slightly
>    different configurations, as those are really just similar but
>    otherwise unrelated services.
> 
>  * Services can take services as arguments, which would become the
>    primary way to construct a dependency graph.  Think of a web
>    application depending on a webserver or the other way around.
> 
>  * We could develop a fully automated way for services in different
>    containers to communicate with each other.
> 
>  * Now people like me can actually use equational reasoning to
>    understand and make predictions about the resulting system.  I can
>    use the fact that the `<>` operator is associative, that certain
>    services are idempotent with respect to `<>` and also that certain
>    functions are morphisms in a rich category.  For example if the
>    nginx function is a monoid morphism, then I know that regardless of
>    how I compose multiple webservers, the result will be a sensible
>    combination of either separate daemons or multiple configurations.
>    This would be extremely valuable.
> 
> The last point is very important, because it basically tells that a
> service is not directly related to what programs will run on the
> resulting system.  Even if you compose ten nginx services, there will be
> only one nginx *program* with a suitable configuration file to represent
> this composition.  It also means that when a service itself comes with
> nginx, then adding another nginx does not actually mean that two
> instances will be running.  If we go as far as to containerise services
> by default, we can make predictions about the container's structure.
> 
> 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. =)
> 
> Let me know what you think.  If this idea finds acceptance, I'm happy to
> develop a formal model and a prototype.
> 
> 
> 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/20141227/c3fc1217/attachment.html