:: Re: [DNG] Dinit service supervisor
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: tito
Fecha:  
A: dng
Asunto: Re: [DNG] Dinit service supervisor
On Sun, 5 Nov 2023 17:20:20 -0500
Steve Litt <slitt@???> wrote:

> 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
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


hi,
its service files looks a lot like titofiles.....

type = process | bgprocess | scripted | internal
command = ...
stop-command = ...
run-as = (user-id)
restart = (boolean)
logfile = ...
pid-file = ...
options = ...
depends-on = (service name)
depends-ms = (service name)
waits-for = (service name)

Ciao,
Tito