:: Re: [DNG] Dinit service supervisor
Top Page
Delete this message
Reply to this message
Author: Steve Litt
Date:  
To: dng
Subject: Re: [DNG] Dinit service supervisor
dng@??? said on Sun, 5 Nov 2023 20:14:05 +0100

>If Dinit has been mentioned before on this list I did not find it.
>
>I came across Dinit when I was looking at the distro Chimera Linux
>(what is in a name) and apparently it is a installable option in Artix
>Linux. And I like their introduction:
>
>/Dinit/is a service supervisor with dependency support which can also
>act as the system "init" program. It was created with the intention of
>providing a portable init system with dependency management, that was
>functionally superior to many extant inits. Development goals include
>clean design, robustness, portability, usability, and avoiding feature
>bloat (whilst still handling common - and some less-common - use
>cases). Dinit is designed to/integrate with/rather than subsume or
>replace other system software.|
>
>We have been discussing init systems before and I think dinit with it
>service description files, its dependencies management and supervisor
>functions is a good contender next to s6.
>
>You can find Dinit at Github https://github.com/davmac314/dinit


I read some of the documentation on the web page you point to,
specifically, the comparison between dinit and other init systems. Yes,
I think it's trying to do the same things as s6 with s6-rc.

Like s6, dinit seems to spend a lot of time protecting against things
that could go wrong. Dinit's definition of "dependency management" is a
lot different from mine, because from my viewpoint there are many ways
to skin a cat. With Daemontools, which I used for many years before
getting runit, and with runit, you declare dependencies of a service by
checking if the dependency is doing its job, and if not, delaying. One
could think of many situations that require more sophisticated
dependency management than runit or Daemontools, but in my at least 5
years with Daemontools and my eight years with runit I've never
knowingly suffered consequences from their sledgehammer DIY dependency
management, nor from their indeterminate daemon startup.

One thing I like about what the Dinit document said is that it made the
distinction between hard and soft dependencies. Based on what they
wrote, I think, but am not sure, that a hard dependency means that if
the dependency doesn't run, the dependent doesn't either. The document
asserts that if a dependency goes down then the dependent goes down
too. I think that with Daemontools and runit the question of whether
the dependent goes down with the dependency depends on the run scripts,
although I *think* you'd need to do a fair amount of work to make the
dependent go down with the dependency in Daemontools or runit.

Dinit sounds interesting.


SteveT

Steve Litt

Autumn 2023 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21