On 11/28, Laurent Bercot wrote:
>  - This mailing-list accepts all discussions about process supervision
> software. It also accepts patches to such software (but rather than cold
> sending patches, please engage in a tech discussion first - it doesn't
> have to be long.)

OK, great!  I just sent my patch series in a separate reply.  I'm happy
to have a tech discussion about it, and I could possibly change the
patch series based on the discussion, or if it is determined that my
patch series should not be accepted, I would accept that as well.

>  - The original author or runit is still subscribed to this list, and
> comes from time to time. However, I'm not aware of an official repo for
> runit, and runit's latest official version has been 2.1.2 for many a year
> now.
>  It looks like several distributions have their own version of runit;
> they are maintained by the distros themselves.
>  - We on the list will gladly help with any question with runit, but to
> be honest, I'm not exactly sure what to do with patch upstream requests
> for runit. Is anyone processing them and integrating them into a new
> release?
This is unfortunate, but I understand and know that things can happen,
priorities can change, time availability can change, etc.  A proper
upstream would be useful.  A bunch of forks does not seem useful to me.
The versions maintained by distros do not seem useful to me because I
suspect that they would not be interested in patches related to distros
or OSes other than their own.

>  - I host this list. I'm also the author of s6, a supervision software
> suite that is very similar to runit in many ways. s6 is actively
> maintained and has a public git repo, and we generally have a quick
> response time with requests.
>  - My opinion is that the most sustainable path forward, for runit
> users who need a centrally maintained supervision software suite, is to
> just switch to s6 - and it comes with several other benefits as well.

OK, I'm open to that.  Thanks for the suggestion!

I don't need an init replacement, and I initially chose daemontools
because it was the original toolset, and I wanted something that could
start and stop a server process that did not daemonize itself.  But
the server that I wanted to manage took a while to actually become
"available," and daemontools didn't support the concept of a service
becoming available sometime after when it was started.  That's when
I found runit which did support the concept of a service becoming
available with its "sv start" command and a "./check" service script.
This way, I could start it and wait for it to become available before
starting something else.

So, if s6 can do something similar, I'd be happy to try it out!  Can it?

My use case is actually to run it as a systemd service, so briefly
looking at


I see something called sdnotify-wrapper, so maybe I should have a look
at that?  (It was mentioned to me off-list.)

>  - But again, I'm not impartial, and alternatives are a good thing.
> So no matter what individual decisions are made, it would definitely be
> a net positive if the exact state and workflow of runit could be
> clarified, and if a real development/maintenance structure was in place.

+1.  Agreed.


Reply via email to