Re: comparison

On 16/06/2015 04:54, Steve Litt wrote: One thing I can tell you is that daemontools and daemontools-encore were never intended to be init systems, whereas I'm pretty sure that runit, s6 and nosh intended to be part or all of an init system. You keep saying that, but at least in the case of run

RE: comparison

I agree Laurent. Though, even though complete init+supervision systems like Runit exist, it's been nearly impossible to get a foothold with any alternatives to sysvinit and systemd effectively. I think one of the major setbacks has been the lack of ready-to-use script sets, like those included

Re: comparison

On Tue, 16 Jun 2015 09:29:15 +0200 Laurent Bercot wrote: > On 16/06/2015 04:54, Steve Litt wrote: > > One thing I can tell you is that daemontools and daemontools-encore > > were never intended to be init systems, whereas I'm pretty sure that > > runit, s6 and nosh intended to be part or all of a

Re: comparison

On Tue, 16 Jun 2015 04:05:29 -0700 James Powell wrote: > I agree Laurent. Though, even though complete init+supervision > systems like Runit exist, it's been nearly impossible to get a > foothold with any alternatives to sysvinit and systemd effectively. I > think one of the major setbacks has be

RE: comparison

Very true, but something always seems to say something along the lines of "if we had done #2 years ago, we might have avoided a huge mess that now exists". Runit could have been the successor to sysvinit years ago, but like anything, unless there is something tangible to import with less work, r

Re: patch: sv check should wait when svrun is not ready

I'd still like to get this merged. Avery: are you the current maintainer? I haven't seen Gerrit Pape on the list. On Tue, Feb 17, 2015 at 4:49 PM, Buck Evan wrote: > On Tue, Feb 17, 2015 at 4:20 PM, Avery Payne > wrote: > > > > On 2/17/2015 11:02 AM, Buck Evan wrote: > >> > >> I think there's

Re: comparison

On 6/15/2015 9:00 PM, Colin Booth wrote: I only know s6 and runit well enough to comment on for the most part but filling in some blanks on your matrix: Updated, thanks for the help. As I said, it's a start. It'll need some time to improve. I mostly needed it for the project, to help me keep

Re: patch: sv check should wait when svrun is not ready

I'm not the maintainer of any C code, anywhere. While I do host a mirror or two on bitbucket, I only do humble scripts, sorry. Gerrit is around, he's just a bit elusive. On 6/16/2015 9:37 AM, Buck Evan wrote: I'd still like to get this merged. Avery: are you the current maintainer? I haven'

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, we might have avoided a huge mess that now exists". Agreed. The same applies to init systems. If there are ready to use feet wetting, taste testing

Re: Readiness notification for systemd

On 6/13/2015 11:48 AM, Laurent Bercot wrote: It's a wrapper for daemons using the simple "write a newline" readiness notification mechanism advertised by s6, which converts that notification to the sd_notify format. This had me tossing around some ideas yesterday while I was headed home. Most

Re: Readiness notification for systemd

On 16/06/2015 20:40, Avery Payne wrote: Logging generally (but not always) implies calling printf() with a newline at some point. What if we could come up with a simple standard that extends your newline concept into the logging output? A newline itself may be emitted as part of a startup strin

RE: comparison

And supervision-scripts has been that generic profile that can be used in 99% of situations. Sadly, Avery, I wish we could have had your work about 8 years ago. The UNIX world might have been a vastly different place. Sent from my Windows Phone From: Avery Payne<

Re: comparison

Implying that the distributions would have transitioned from System V-style to daemontools-style mechanisms? Strongly doubt it. For all the noise and controversy that's been happening over PID1, I always got the impression that most distros back in the day simply didn't care. They happily pil

Re: comparison

That's an understatement! And, as the old saying goes, the best time to plant a tree is 20 years ago. The second best time is today. Thanks Avery! SteveT On Tue, 16 Jun 2015 13:09:32 -0700 James Powell wrote: > And supervision-scripts has been that generic profile that can be > used in 99%

RE: comparison

Too true. Systemd offered the pot of gold as long as you handed it the keys to the kingdom. Runit still requires work, but less work if a package for scripts exists. The most arbitrary need is the Stage scripts, which generally can utilize a general script setup, or translated init shell script

Re: comparison

On 6/16/2015 1:32 PM, post-sysv wrote: Soon systemd arrives with its promise of being a unified userspace toolkit that systems developers can supposedly just plug in and integrate without hassle to get X, Y and Z advantages. No more writing initscripts, no more setting policy because systemd

s6 ordering and run-once?

Hi all, I'm studying the s6 website. The only reference I found to controlling startup order was a sentence about creating symlinks one by one. I found a sentence about run-once types of things (I think the example was bringing up the network), but then it didn't tell me *how* to run a run-once.

Re: comparison

On Tue, 16 Jun 2015 14:12:48 -0700 Avery Payne wrote: > > > On 6/16/2015 1:32 PM, post-sysv wrote: > > Soon systemd arrives with its promise of being a unified userspace > > toolkit that systems developers can supposedly just plug in and > > integrate without hassle to get X, Y and Z advantag

Towards a clearinghouse

On Jun 16, 2015 2:39 PM, "Steve Litt" wrote: > > On Tue, 16 Jun 2015 14:12:48 -0700 > Avery Payne wrote: > > > > In my not very humble opinion, we really need a single point of > > reference, driven by the community, shared and sharable, and publicly > > visible. I could envision something like

Re: Towards a clearinghouse

Avery: copy the stylesheet from cr.yp.to. It seems to be the cool thing recently.

Re: s6 ordering and run-once?

On 16/06/2015 23:33, Steve Litt wrote: Hi all, I'm studying the s6 website. The only reference I found to controlling startup order was a sentence about creating symlinks one by one. I found a sentence about run-once types of things (I think the example was bringing up the network), but then it

Re: Towards a clearinghouse

On 17/06/2015 00:08, Buck Evan wrote: Avery: copy the stylesheet from cr.yp.to. It seems to be the cool thing recently. Eh, it was never intended to be cool. It was more like "default HTML without stylesheets is readable and it's all I need, I don't want to learn CSS or invest time to make it

Re: comparison

On 16/06/2015 22:32, post-sysv wrote: Soon systemd arrives with its promise of being a unified userspace toolkit that systems developers can supposedly just plug in and integrate without hassle to get X, Y and Z advantages. No more writing initscripts, no more setting policy because systemd will

RE: comparison

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

Re: Towards a clearinghouse

Avery, Laurent: This pycon lightning talk gave some really good, quick tips that I think you may like: https://youtu.be/JVVMMULwR4s?t=29m19s On Tue, Jun 16, 2015 at 4:17 PM, Laurent Bercot wrote: > On 17/06/2015 00:08, Buck Evan wrote: > >> Avery: copy the stylesheet from cr.yp.to. It seems to

First thoughts on s6

Hi all, I have a proof of concept s6 running, *supervision only*, on a Plop Linux VM. It is started by sysvinit (inittab), and supervises tty5 just fine, including logging (which is how I found out my run command originally had bad syntax). Here are some first impressions... Plop Linux has one o

Re: s6 ordering and run-once?

On Wed, 17 Jun 2015 01:07:01 +0200 Laurent Bercot wrote: > On 16/06/2015 23:33, Steve Litt wrote: > > Hi all, > > Does anyone know how to do a run-once service without putting an > > infinite sleep loop at the end? > > Oneshots are not meant to be supervised. Don't create a service > director

Re: First thoughts on s6

On 17/06/2015 02:44, Steve Litt wrote: Plop Linux has one of those /dev/random generators that just stops after a few characters. This caused the ./configure on skalibs to lock up while checking for /dev/random (thank you very much for the clear messages). In fact, /dev/random on this VM locks up

Re: s6 ordering and run-once?

On 17/06/2015 02:58, Steve Litt wrote: What do you do if a oneshot requires that a longrun is already running? That is exactly the problem of mixed dependencies. The right answer is anopa (or s6-rc when it's released). Apart from that, I don't have any more of an answer than runit or daemont

Re: First thoughts on s6

On Tue, Jun 16, 2015 at 5:44 PM, Steve Litt wrote: > Hi all, > > I'd suggest a ./configure option called --urandom-instead, because this > isn't the first time I've seen a /dev/random act like this, and > probably most people don't want to pull the strongarm I did (I wouldn't > either if it were a

Re: s6 ordering and run-once?

On Tue, 16 Jun 2015 20:58:35 -0400 Steve Litt wrote: > > > Does anyone know how to do a run-once service without putting an > > > infinite sleep loop at the end? In perp you would simply touch(1) a file named "flag.once" in the service definition directory. See the section STARTUP MODIFICATION

Re: s6 ordering and run-once?

On Tue, Jun 16, 2015 at 5:58 PM, Steve Litt wrote: > On Wed, 17 Jun 2015 01:07:01 +0200 > Laurent Bercot wrote: > >> On 16/06/2015 23:33, Steve Litt wrote: >> > Hi all, > >> > Does anyone know how to do a run-once service without putting an >> > infinite sleep loop at the end? >> >> Oneshots ar

Re: comparison

On Tue, 16 Jun 2015 09:29:15 +0200 Laurent Bercot wrote: > In the meantime, if you don't want to get your hands dirty, > you can still use s6-svscan/s6-supervise as a process supervision > system without trying to make it run as an init system, just as you > can use runsvdir/runsv as a process