runit or s6 (was: runit patches to fix compiler warnings on RHEL 7)
For submitting patches, I'd recommend working with the Void Linux project. They can be found at #xbps on Freenode IRC. Void Linux has used runit as their init system for the past 5 years: Their implementation is very reliable and mature. Yes, but OP wants to fix compiler warnings on RHEL7. Do you think Red Hat uses Void as their runit upstream? IMHO not necessarily. There are people whose top priority is simplicity. You love to prop up the discourse that runit is a lot simpler than s6, but I reject this assumption, and you're doing a disservice to me *and* to users by propagating it. Core runit and core s6 are very similar, and the complex parts of s6 are entirely optional. The part where runit is definitely simpler than s6 is when both are used as init systems, which is entirely optional too. Again, OP is talking about RHEL7: what are the odds runit is used as an *init system* on RHEL7? so the bulk of the "simplicity" argument falls here. Which leads to the next point: One reason runit has such a large mindshare is because Void Linux and maybe some others ship with runit as their init. s6 has an opportunity to leapfrog. Right now, the Devuan project is discussing supplying run scripts for runit and for s6. The Devuan people know me well. They know where to contact me. They know I'm interested in helping as much as I can if they choose s6. I haven't heard from them. So, I'm assuming they're not really interested. If I'm wrong, my mailbox is open. Anyway, if you have a bunch of known-good s6 run (and finish) scripts curated somewhere, everyone would be pleased if you let the Devuan user mailing list know where they are. It's been the same tune for years, so please believe that I know it well. *Everybody* is in love with s6 as long as everything is turnkey (read: as long as software authors, who are supposed to provide mechanism, are also providing policy, i.e. doing the work of the distribution). But as soon as the distribution actually has to *do its job*, stop being lazy, and write policy scripts, suddenly there's no one around. Crickets. I've learned the lesson. I will provide a complete set of init scripts. And I'm slowly getting to the point where I'll be able to do it. But I'll still need 2 more years, because I need to feed myself, too. If more people/distros were *really* interested in this, instead of just nodding their heads and paying lip service as long as they don't have to lift a finger (yes, I'm looking at you too, Steve), it would go a lot faster. It would most likely already be done. You can help by cutting the nagging. -- Laurent
Re: runit patches to fix compiler warnings on RHEL 7
On Thu, 28 Nov 2019 19:04:37 + "Laurent Bercot" wrote: > - 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? For submitting patches, I'd recommend working with the Void Linux project. They can be found at #xbps on Freenode IRC. Void Linux has used runit as their init system for the past 5 years: Their implementation is very reliable and mature. > > - 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. IMHO not necessarily. There are people whose top priority is simplicity. They value simplicity over guaranteeing against a machine whose supervisor has died, and is now incommunicado. They value simplicity over PID1's ability to supervise one program; the process supervisor (did I get that right?). Such people would prefer runit. Additionally, if a person uses sysvinit as PID1 and only PID1, and puts "respawn runsvdir" in /etc/inittab, then they do get PID1 supervising the supervisor. One other observation: If I wanted the Cadillac of the industry, I'd go with s6. But on a day to day basis, the Chevy of the industry, runit, is good enough for the driving I do. Which leads to the next point: One reason runit has such a large mindshare is because Void Linux and maybe some others ship with runit as their init. s6 has an opportunity to leapfrog. Right now, the Devuan project is discussing supplying run scripts for runit and for s6. Assuming Debian ship with a working s6 (only has to work as a supervisor: sysvinit could be PID1), if the s6 run scripts arrive first, I think s6 would be in a position to become Devuan's default supervisor a year or two from now. I spoke the preceding sentence as an individual, not as a member of the Devuan community. Anyway, if you have a bunch of known-good s6 run (and finish) scripts curated somewhere, everyone would be pleased if you let the Devuan user mailing list know where they are. Thanks, SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr
Re: runit patches to fix compiler warnings on RHEL 7
I am reluctant to bring this up because I am not a neutral third party, but this is frankly a conversation that needs to be had. - 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.) - 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? - 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. - 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. -- Laurent
Re: runit patches to fix compiler warnings on RHEL 7
On 27.11.19 21:33, J. Lewis Muir wrote: > On 11/25, J. Lewis Muir wrote: >> Is runit hosted in a public source code repo? If so, where? >> >> Are patches to fix runit compiler warnings on RHEL 7 welcome? > > I have patches now. Is there a public source code repo I can contribute > against? Or would it be helpful to just send the patches to the list? AFAIK you have to post them to this list. Martin
