Runit work we've been up to.

Even though our work with s6 is on hold at the moment, I wanted to take some time to let you all know that we've been working on our Runit-for-LFS implementation, and we've hit several milestones worth mentioning. 1. We've solved our long-running Stage 3 shutdown issue with drives not being

Runit design for LFS.

Figured I'd get some feedback on this: I've currently crafting the next major release of Runit for LFS as both a replacement for the LFS-Bootscripts and BLFS-Bootscripts packages I plan to dub as LFS-Runit-Services. The focus of the design will center around a stand-alone stage-1 for booting

RE: Rare runsv logging problem

My question is why are you running Upstart? Runit has it's own init so Upstart is pointless. Runit's binary should maintain runsv. It also could depend on the run script also having an improper handling. Sent from my Windows Phone From: Caleb

RE: Rare runsv logging problem

Another thing could be that the service may not need a log. I've directed a lot of unwanted output to /dev/null. Can you post one of your run files as an example? Sent from my Windows Phone From: James Powellmailto:james4...@hotmail.com Sent: ‎7/‎25/‎2014 9:35

RE: [PATCH] Implement stage 4 (execve handoff)

Might be good for a bootdisk scenario in some ways as FINNIX does. However outside that, I would have only speculation for a real time system. Still intriguing to say the least. Date: Fri, 1 Aug 2014 10:20:10 + From: p...@smarden.org To: supervision@list.skarnet.org Subject: Re:

RE: License selection for process scripts

I licensed runit-for-lfs under the MIT license because I wanted people to have the choice of contributing without compulsion. They can reuse the work, but we still have to be referenced only if work was derived. Sent from my Windows Phone From: Laurent

RE: Transition to supervision-scripts

Date: Mon, 3 Nov 2014 10:41:05 -0800 Subject: Transition to supervision-scripts From: avery.p.pa...@gmail.com To: supervision@list.skarnet.org The transition is complete and all framework-specific dependencies are being replaced with generic redirects. The runit-scripts repository will

RE: New linux distribution using runit

Void has been on our radar for several months now. It actually was a systemd distribution, but reverted to Runit and eudev after several months time. Sent from my Windows Phone From: Martin Födingermailto:foedinger.mar...@gmail.com Sent: ‎12/‎6/‎2014 3:26 AM To:

RE: runit-scripts gone, supervision-scripts progress

Hey Laurent, Over at LQ, I'm working on importing s6 into LFS again, but this time at a slower pace. I was hoping to also see about using the native LFS utilities as much as possible and only include the init-shim tools (halt, shutdown, pause, and runlevel scripts and binaries) from

RE: [announce] s6-2.0.1.0

Going to pull the new version as soon as I can to test in LFS. Thanks Laurent. Sent from my Windows Phone From: Laurent Bercotmailto:ska-supervis...@skarnet.org Sent: ‎1/‎13/‎2015 6:15 PM To: supervision@list.skarnet.orgmailto:supervision@list.skarnet.org

RE: first round of optional dependency support

Service scripts often need a lot of setup code before the actual daemon is executed. My question is, does it provide a fail-safe solution to dependency trees? Shutdown is only an issue if you need a finish script, otherwise the service supervisor will execute the kill signal and bring things

RE: redoing the layout of things

Avery, as a good rule of thumb, stick to what you know is best and do what you feel is the simplest method with the greatest functionality. If hidden directories work to help things work better, use them. Besides, if it already works, why change it? Sent from my Windows Phone

RE: s6 init-stage1

The problem of using sockets rather than named pipes is that each UNIX socket requires more POSIX shared memory increasing the system resource base requirements. Named pipes just use normal process memory which keeps system requirements less. How Lennart failed to mention that in the systemd

RE: thoughts on rudimentary dependency handling

I'll be following this intently as I have a project I'm working on that will use s6 heavily even discretely. Sent from my Windows Phone From: Avery Paynemailto:avery.p.pa...@gmail.com Sent: ‎1/‎7/‎2015 11:58 PM To:

RE: move s6 to github?

I think s6 is fine how it is. Currently many related projects exist on githib that can help or assist s6, but they are not developed solely on githib. Runit-for-LFS was based in GoogleCode for logistical reasons until Google pulled the plug on us. I also see s6 not as a true Cathedral, but as

RE: staggering runsv startup

If runit had the ability to order processes like OpenRC where you have: before= after= setups, you could order the entire tree structure. The problem with sv check is the command often can only check the status of the service. Sent from my Windows Phone From:

RE: runit maintenance - Re: patch: sv check should wait when svrun is not ready

You could always craft a rudimentary Makefile, autogen.sh, and configure script set in the tree root that can be used. Then again, I like others, just do install -v XXX and cp -a to the files to directories as needed anyways, and retune to sv scan default directory in patch. Sent from my

RE: comparison

Paynemailto:avery.p.pa...@gmail.com Sent: ‎6/‎16/‎2015 11:26 AM To: supervision@list.skarnet.orgmailto:supervision@list.skarnet.org Subject: Re: comparison On 6/16/2015 5:22 AM, James Powell wrote: Very true, but something always seems to say something along the lines of if we had done #2 years ago

RE: comparison

You really do have to cater to get a foothold in the door any more. Sent from my Windows Phone From: Laurent Bercotmailto:ska-supervis...@skarnet.org Sent: ‎6/‎16/‎2015 4:24 PM To: supervision@list.skarnet.orgmailto:supervision@list.skarnet.org Subject: Re:

RE: [ale] systemd talk from July has slide deck online now

I have wondered if OpenRC could have scripts that hook into s6 to start services via s6 and run in supervision mode while having OpenRC manage order of process startup and sysvinit handles the remainder of init functionality. In a way you combine sysvinit, OpenRC, and s6 in a harmonious union.

RE: [ale] systemd talk from July has slide deck online now

e.org> Cc: supervision@list.skarnet.org<mailto:supervision@list.skarnet.org> Subject: Re: [ale] systemd talk from July has slide deck online now On 09/08/2015 11:44 PM, James Powell wrote: > I have wondered if OpenRC could have scripts that hook into s6 to start > services via s6 and

RE: Some suggestions about s6 and s6-rc

et.org<mailto:supervision@list.skarnet.org> Subject: Re: Some suggestions about s6 and s6-rc On 19/09/2015 14:52, James Powell wrote: > I don't see it, rc_parallel, as entirely broken, that is if you > follow proper scripting techniques and create the proper dependency > prestarts.

RE: OpenRC findings (was: Some suggestions about s6 and s6-rc)

A lot of problems still stem from the fact most scripts are still written in Bash with sysvinit-isms embedded within. OpenRC and the service init scripts could possibly be modernized further than they are to use s6, runit, or daemontools-encore style and using commands and even use possibly

RE: Determining the running init

From: Steve Litt Sent: Monday, May 2, 2016 4:18 PM To: supervision@list.skarnet.org Subject: Re: Determining the running init On Mon, 02 May 2016 16:20:20 -0400 James Cloos wrote: > I don't have a runit system up right now. > > Could someone show me what: > >   lsof -a