Re: init.d script names

On Thu, Oct 2, 2014 at 7:01 PM, Charlie Brady charlieb-supervis...@budge.apana.org.au wrote: On Thu, 2 Oct 2014, Avery Payne wrote: On Thu, Oct 2, 2014 at 3:55 PM, Laurent Bercot ska-supervis...@skarnet.org wrote: Yeah, unfortunately that's not going to happen. You might get

Re: init.d script names

It's a harder problem than it looks, really, and all the easy way outs are hackish and will fail horribly when you least expect it. So, should I stop work on runit-scripts and s6-scripts? If this is all for naught, then why put the effort in?

Re: another distro using runit...

On Mon, Oct 20, 2014 at 10:52 AM, John Albietz inthecloud...@gmail.com wrote: Re: runit, a few things I've run into: - I haven't found a way to lower the default wait time on init start from the current default 1 second. Also not sure if there's a way to lower the runsvdir service poll timer

License selection for process scripts

This may sound a bit off-topic but it has a practical purpose. Currently I am working under the assumption that a BSD 3-Clause license may be sufficient to provide process control scripts for daemontools, runit, and s6. However, each has a different license. I need to find a license that

Process Dependency?

I know that most process management tools look at having the script do the heavy lifting (or at least carry the load by calling other tools) when trying to bring up dependencies. Couldn't we just have a (service)/needs directory? The idea is that the launch program (s6-supervise or runsv) would

Fwd: Process Dependency?

A message was dropped...passing it along as part of the discussion -- Forwarded message -- From: Casper Ti. Vector caspervec...@gmail.com Date: Fri, Oct 31, 2014 at 3:37 AM Subject: Re: Process Dependency? To: Avery Payne avery.p.pa...@gmail.com Sorry, but I just found that I did

Re: Process Dependency?

Part of the temptation I've been fighting with templates is to write the grand unified template, that does it all. It sounds horrible and barely feasible, but the more I poke at it, the more I realize that there is a specific, constrained set of requirements that could be met in a single

Re: runit-scripts transitions to supervision-scripts

Just curious, but does anyone else have issues seeing some messages on the mailing list? My last message won't load through the web interface on skarnet. On Fri, Oct 31, 2014 at 3:06 PM, Avery Payne avery.p.pa...@gmail.com wrote: The work on runit-scripts will officially cease December 31

Transition to supervision-scripts

The transition is complete and all framework-specific dependencies are being replaced with generic redirects. The runit-scripts repository will be deleted January 1st.

use of envdir

Just a quick poll, anyone here using the envdir feature? Is it widely supported, or do people even bother?

Re: use of envdir

That's three yes, I do! responses in less than an hour. I'd say it's somewhat popular. :) Thank you for your responses. On Mon, Nov 3, 2014 at 10:41 AM, Avery Payne avery.p.pa...@gmail.com wrote: Just a quick poll, anyone here using the envdir feature? Is it widely supported, or do people

Re: Transition to supervision-scripts

On Fri, Nov 7, 2014 at 1:09 PM, John Albietz inthecloud...@gmail.com wrote: I'd love to help with this. Any way we can move the runit scripts to github instead of svn / googlecode? True, runit-for-lfs is svn hosted, and supervision-scripts is mercurial. But git should push/pull both with

supervision-scripts is now licensed

The project is now assigned the Mozilla Public License 2.0. If you have questions about this, please contact me directly instead of asking/posting on the mailing list, as per the list owner's request.

Re: Missing files /etc/init.d/rcS and rmnologin

On Tue, Dec 16, 2014 at 8:54 AM, Steve Litt sl...@troubleshooters.com wrote: Thanks Avery, First of all, I eventually overcame these problems, so this email is pretty much confirmation of what you wrote. Cool! So now I've removed both systemd and sysvinit from the equation. My next task

Re: Using runit-init on debian/Jessie in place of sysvinit/systemd

On Fri, Jan 2, 2015 at 6:51 AM, Luke Diamand l...@diamand.org wrote: On 02/01/15 10:40, Avery Payne wrote: On Thu, Jan 1, 2015 at 3:39 PM, Luke Diamand l...@diamand.org wrote: Caution, a shameless plug follows: If you are willing to share the contents of your scripts with a very

runit-scripts gone, supervision-scripts progress

Happy belated New Year! As discussed elsewhere, the runit-scripts repository has been removed. A link has been left that redirects to the supervision-scripts project. The new project should be a 100% compatible replacement. I did not achieve my personal goal of a 0.1 release by January 1. I

Re: runit-scripts gone, supervision-scripts progress

On Fri, Jan 2, 2015 at 3:42 PM, James Powell james4...@hotmail.com wrote: Anyways, I'll be posting more frequently about getting init-stage-1/2/3 drafted correctly and in execline script language. Avery maybe you can share your notes as well on this with me, if possible. I'll provide what

Re: runit-scripts gone, supervision-scripts progress

One way or the other, ./finish should only be used scarcely, for clean-up duties that absolutely need to happen when the long-lived process has died: removing stale or temporary files, for instance. Those should be brief operations and absolutely cannot block. I'm thinking spawn to

supervision scripts, 2015-01

Lots of changes behind the scenes. Not as many new definitions, although things will return to normal in the next month. Done: - - - - - - - - + New! Internal framework-neutral command grammar. Upon selecting a given framework, all scripts automatically use the correct start and check

Re: thoughts on rudimentary dependency handling

On 1/19/2015 2:31 PM, Jonathan de Boyne Pollard wrote: Avery Payne: * implement a ./wants directory. [...] * implement a ./needs directory. [...] * implement a ./conflicts directory. [...] Well this looks familiar. I ducked out of ./needs and ./conflicts for the time being; if I spend

Re: Could s6-scscan ignore non-servicedir folders?

On 1/21/2015 7:19 PM, post-sysv wrote: I'm not sure what effective and worthwhile ways there are to express service *relationships*, however, or what that would exactly entail. I think service conflicts and service bindings might be flimsy to express without a formal system, though I don't

first round of optional dependency support

Ok, admittedly I'm excited because it works. The High Points: + It works (ok, yeah, it took me long enough.) + Framework-neutral grammar for bringing services up and checking them, no case-switches needed + Uses symlinks (of course) to declare dependencies in a tidy ./needs directory + Can do

Re: first round of optional dependency support

things down. Sent from my Windows Phone -- From: Avery Payne avery.p.pa...@gmail.com Sent: ‎1/‎15/‎2015 9:11 PM To: supervision@list.skarnet.org Subject: first round of optional dependency support Ok, admittedly I'm excited because it works. The High Points

Re: s6 init-stage1

On Tue, Jan 6, 2015 at 4:02 AM, Laurent Bercot ska-supervis...@skarnet.org wrote: I very much dislike having / read-write. In desktops or other systems where /etc is not really static, it is unfortunately unavoidable (unless symlinks to /var are made, for instance /etc/resolv.conf should be

redoing the layout of things

On Thu, Jan 8, 2015 at 3:08 PM, Luke Diamand l...@diamand.org wrote: On 08/01/15 17:53, Avery Payne wrote: The use of hidden directories was done for administrative and aesthetic reasons. The rationale was that the various templates and scripts and utilities shouldn't be mixed in while

Re: thoughts on rudimentary dependency handling

On Tue, Jan 6, 2015 at 10:20 AM, Laurent Bercot ska-supervis...@skarnet.org wrote: I firmly believe that a tool, no matter what it is, should do what the user wants, even if it's wrong or can't possibly work. If you cannot do what the user wants, don't try to be smart; yell at the user,

Re: thoughts on rudimentary dependency handling

On Wed, Jan 7, 2015 at 6:53 PM, Laurent Bercot ska-supervis...@skarnet.org wrote: Unfortunately, the envdir tool, which I use to abstract away the daemons and settings, only chain-loads; it would be nice if it had a persistence mechanism, so that I could load once for the scope of the shell

Re: thoughts on rudimentary dependency handling

The use of hidden directories was done for administrative and aesthetic reasons. The rationale was that the various templates and scripts and utilities shouldn't be mixed in while looking at a display of the various definitions. The other rationale was that the entire set of definitions could be

RE: thoughts on rudimentary dependency handling

On Wed, Jan 7, 2015 at 7:23 AM, Steve Litt sl...@troubleshooters.com wrote: I'm pretty sure this conforms to James' preference (and mine probably) that it be done in the config and not in the init program. To satisfy Laurent's preference, everything but the exec cron -f could be commented

Re: thoughts on rudimentary dependency handling

On Tue, Jan 6, 2015 at 8:52 AM, Laurent Bercot ska-supervis...@skarnet.org wrote: I'm not sure exactly in what context your message needs to be taken - is that about a tool you have written or are writing, or something else ? - but if you're going to work on dependency management, it's

Re: thoughts on rudimentary dependency handling

On Thu, Jan 8, 2015 at 9:23 AM, Steve Litt sl...@troubleshooters.com wrote: I'm having trouble understanding exactly what you're saying. You mean the executable being daemonized fails, by itself, because a service it needs isn't there, right? You *don't* mean that the init itself fails,

POLL: what installations would you use process supervision in?

This is a simple straw poll. Please do *not* reply to the mailing list - I don't want to clog it with answers. Send the replies directly to my personal email address instead. The poll will remain open until March 31, and I will publish results after that time. POLL: what installations

POLL RESULTS: what installations would you use process supervision in?

There were 8 respondents. [ 4 ] A hand-made / hand-customized Linux installation [ 1 ] A commercial installation (HP-UX, AIX, Pre-Oracle Solaris) [ 2 ] an installation made with LFS [ 2 ] an installation made with Gentoo [ 0 ] an installation made with Arch [ 3 ] an installation made with

Re: anopa: init system/service manager built around s6

On 4/10/2015 6:41 PM, Aristomenis Pikeas wrote: Laurent (s6-rc), Olivier (anopa), Toki (supervision framework), and Gorka (s6-overlay), I'm having a lot of trouble figuring out the differences between your projects. The s6 suite of utils can be considered building blocks for a full init

Re: Another attempt at S6 init

On 4/21/2015 7:34 AM, TheOldFellow wrote: So I should need much less than Laurent has in his example. (did I mention the ancient grey cells?) I'm no expert at execline, so I'm taking wild guesses here based on the little bits that I know from reading about it. #close stdout and stderr

Re: dependant services

On 4/21/2015 2:19 PM, Buck Evan wrote: Does s6 (or friends) have first-class support for dependant services? I know that runit and daemontools do not. I do know that nosh has direct support for this. I believe s6 supports it through various intermediary tools, i.e. using socket activation to

Re: dependant services

On 4/21/2015 2:56 PM, Buck Evan wrote: My understanding of s6 socket activation is that services should open, hold onto their listening socket when they're up, and s6 relies on the OS for swapping out inactive services. It's not socket activation in the usual sense.

Re: dependant services

On 4/21/2015 3:08 PM, Buck Evan wrote: On Tue, Apr 21, 2015 at 2:46 PM, Avery Payne avery.p.pa...@gmail.com mailto:avery.p.pa...@gmail.com wrote: Alternatively, are there general-purpose practices for breaking this kind of dependency? Strange as it sounds

Re: Thoughts on First Class Services

Dang it. Hit the send button. It will be a bit, I'll follow up with the completed email. Sorry for the half-baked posting.

Re: Thoughts on First Class Services

Note: this re-post is due to an error I made earlier today. I've gutted out a bunch of stuff as well. My apologies for the duplication. On 4/28/2015 11:34 AM, Laurent Bercot wrote: I'm also interested in Avery's experience with dependency handling. Hm. Today isn't the best day to write

Re: Thoughts on First Class Services

On 4/28/2015 10:50 AM, bougyman wrote: Well at least we're talking the same language now, though reversing parent/child is disconcerting to my OCD. Sorry if the terminology is reversed. Here's the current version of run.sh, with dependency support baked in:

Re: Thoughts on First Class Services

On 4/28/2015 11:34 AM, Laurent Bercot wrote: If a lot of people would like to participate but don't want to subscribe to the skaware mailing-list, I'll move the thread here. Good point, I'm going to stop discussion here and go over there, where the discussion belongs.

Re: Thoughts on First Class Services

On 4/28/2015 10:31 AM, Steve Litt wrote: Good! I was about to ask the definitions of parent and child, but the preceding makes it clear. I'm taking it from the viewpoint that says the service that the user wishes to start is the parent of all other service dependencies that must start.

Re: Arch Linux derivative using s6?

On 5/14/2015 3:47 PM, Jonathan de Boyne Pollard wrote: There are even more than that. I mentioned back in January that the nosh Guide chapter on creating service bundles has pointers to the run file collections by Gerrit Pape, Wayne Marshall, Kevin J. DeGraaf, and Glenn Strauss. I also

Re: Arch Linux derivative using s6?

On 4/19/2015 7:03 AM, John Regan wrote: It's not quite the same, but I think Alpine linux is pretty close to what you're looking for. They'd probably love to get more people involved, writing documentation, making packages, etc. It doesn't use s6, but I've submitted the s6 packages to the

Re: dependant services

On 6/8/2015 10:44 AM, Steve Litt wrote: Just so we're all on the same page, am I correct that the subject of your response here is *not* socket activation, the awesome and wonderful feature of systemd. You're simply talking about a service opening its socket before it's ready to exchange

Re: dependant services

On 6/8/2015 2:15 PM, Steve Litt wrote: I'm not familiar with inetd. Using sockets to activate what? In what manner? Whose socket? ~ ~ ~ Let's go back in time a little bit. The year is 1996, I'm downstairs literally in my basement with my creaky old 486 with 16Mb of RAM and I'm trying to

Re: dependant services

On 5/14/2015 3:25 PM, Jonathan de Boyne Pollard wrote: The most widespread general purpose practice for breaking (i.e. avoiding) this kind of ordering is of course opening server sockets early. Client and server then don't need to be so strongly ordered. This is where I've resisted using

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

On 6/20/2015 3:58 AM, Lasse Kliemann wrote: Gerrit Pape p...@smarden.org writes: First is moving away from slashpackage. Doing it similar to what Laurant does in his current projects sounds good to me, but I didn't look into details. This even might include moving away from the djblib

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

On 6/18/2015 6:24 PM, Buck Evan wrote: Thanks Gerrit. How would you like to see the layout, build process look? Maybe there's an example project you like? If it's easy enough for me to try, I'd like to. I pulled Gerrit's stuff into bitbucket a few days ago. The first step I would humbly

A general sequence of events for init

I have this crazy dream. I dream that, for supervision-styled frameworks, there will be a unified init sequence. * It will not matter what supervision framework you use. All of them will start properly after the init sequence completes. * It will not matter how sophisticated your

Re: A general sequence of events for init

On 6/22/2015 6:42 PM, post-sysv wrote: Handling stages 1 and 3 may need some additions to conditional logic, however. The idea would be that different plugins would represent some abstract notion at some stage in the boot process, i.e. mount the root filesystem would be abstracted away to a

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

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: 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

Towards a clearinghouse

On Jun 16, 2015 2:39 PM, Steve Litt sl...@troubleshooters.com wrote: On Tue, 16 Jun 2015 14:12:48 -0700 Avery Payne avery.p.pa...@gmail.com wrote: In my not very humble opinion, we really need a single point of reference, driven by the community, shared and sharable, and publicly

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

haven't seen Gerrit Pape on the list. On Tue, Feb 17, 2015 at 4:49 PM, Buck Evan b...@yelp.com mailto:b...@yelp.com wrote: On Tue, Feb 17, 2015 at 4:20 PM, Avery Payne avery.p.pa...@gmail.com mailto:avery.p.pa...@gmail.com wrote: On 2/17/2015 11:02 AM, Buck Evan wrote: I

Re: comparison

I'm working on something similar, but you're asking for capabilities, and most of what I have is a mapping. I've tried to include a few critical links in the comparison for the various homepages, licenses, source code, etc. It's incomplete for now, but it's a start.

Re: machine api to supervise

It would be nice to develop a common "grammar" that describes whatever is being probed. If the grammar was universal enough, you could fill in empty strings or zeros for things that don't apply, but the interpreter for the state data need only be written once. The following pipe-dream passes

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

On 9/9/2015 9:57 AM, Laurent Bercot wrote: Quoting the document: "This article is not meant to impart any technical judgments, but to simply document what has been done". I don't think the author of the document is condoning XML configuration any more than you and I are. (Context: VR is also

supervision-scripts 2015-08

Done: - - - - + New definitions: clamd, cpufreqd. + Definitions are now versioned. The ./envdir directory is now a symlink to another directory that contains the proper definitions for a given version of software. This solves a long standing problem of "version 1 is different from version

Re: Some suggestions about s6 and s6-rc

With regard to having scripted placement of down files, if it was in a template or compiled as such, then the entire process of writing it into the definition becomes trivial or moot. While there should always be a manual option to override a script, or the option to write one directly, I think

Re: Built-in ordering

Regarding the use of ordering during "stage 1", couldn't you just have a single definition for stage 1, run through it to set up whatever is needed, then transition to a new system state that doesn't include that defintion with (insert system management here)? What I am trying to ask is if the

[announce] supervision-scripts to be retired

Since I began what amounts to my first open source project - ever - I have learned a lot in the process, met several interesting characters, and hopefully provided some insights to a few others as well. To everyone over the last year and half that have put up with me, thank you for giving me

Re: runit kill runsv

I am try to reproduce situation when runsv under some catastrophic failure, when runsv got killed, it will restart, but my test daemon "memcached" still running on background, eventually it will start memcached twice. How could I avoid this from happening? Seems fault handling isn't that

Re[2]: error on logging and how to correctly implement svlogd?

Hi, Thanks for replying. I don't use symlink, instead I put everything directly on /etc/service/test, then sv start test Try this: mkdir /etc/svcdef mkdir /etc/svcdef/test mkdir /etc/svcdef/test/log Put a copy of your test service ./run file into the new directory: cp

Re: The plans for Alpine Linux

On 2/3/2016 9:30 AM, Steve Litt wrote: Hi Laurent, The situation you describe, with the maintainer of a distro's maintainer for a specific daemon packaging every "policy" for every init system and service manager, is certainly something we're working toward. But there are obstacles: * Daemon

unit2run.py, a Python script for converting systemd units

I'm announcing the 0.1 release of unit2run.py, which is a small brain-damaged hack that attempts to create a ./run file from a systemd unit. It is released under the ISC license. The following features are available: * It will pump out a horrifically formatted shell script. It might even be

Re: [DNG] Supervision scripts (was Re: OpenRC and Devuan)

Regarding the use of supervision-scripts as "glue" in distributions, yes, the project was meant for that. Most - but not all of - the scripts are in working order, as I use them at home on my personal server. If you are willing to take the time to remap the names (as needed), the scripts should

Re: listen(1): proposed addition to the runit suite

On 8/22/2016 6:57 AM, Gerrit Pape wrote: But beware, directory layout, build and release processes are from around 2001, and might not be as modern as expected ;). With just a minor hack, I was able to get a clean build without slashpackage interference. It might not need that much cleanup

Re: [announce] Release 0.2 of rc-shim

Seems like I'm always forgetting something... https://bitbucket.org/avery_payne/rc-shim I need to rewrite the README. You'll want to edit the settings in os-settings and supervisor-settings. Feedback is always appreciated. If you have questions, contact me outside of the mailing list.

[announce] Release 0.2 of rc-shim

I'm pleased to announce the release of rc-shim v0.2, a small script that is useful for adding supervision to existing installations using SysV-styled rc scripts. The script replaces existing /etc/init.d scripts with a shim that interfaces to a supervisor of your choice. It should support any

Re: Runit questions

On Tue, Oct 11, 2016 at 3:09 PM, Andy Mender wrote: > Hello again, > > I'm rewriting some of the standard sysvinit and openrc scripts to ./run > scripts > I would look around a bit. There are little pockets of pre-written scripts out there, you just need to dig them

Re: Runit questions

I hate using webmail. It always eats your formatting. The script shows up as a block of text in the mailing list because of this; just click the link for the project and look for the run-svlogd script. You'll find what you need there. On Sun, Oct 16, 2016 at 1:16 PM, Avery Payne <avery.p

Re: Runit questions

On Sat, Oct 15, 2016 at 3:28 PM, Andy Mender wrote: > Hello everyone, > > I managed to solve some of my problems. It turned out that my terminal was > being spammed > with erroneous output, because I didn't add the "exec 2&>1" redirection to > my ./run files. > This

[announce] Release 0.1 of rc-shim

I'm announcing the initial release of rc-shim, a small script that is useful for adding supervision to existing installations using SysV-styled rc scripts. The script replaces existing scripts in /etc/init.d with a shim that interfaces to an existing supervisor. It should support any

[announce] release 0.2.2 of rc-shim

I'm announcing the release of rc-shim v0.2.2, a small script that is useful for adding supervision to existing installations already using SysV-styled rc scripts. I was going to withhold this announcement until the 0.3 release, but there were some bugs that needed to be addressed. The

[announce] release 0.2.3 of rc-shim

I'm announcing the release of rc-shim v0.2.3, a small script that is useful for adding supervision to existing installations already using SysV-styled rc scripts. At this point the shim appears to be fairly stable. The following has changed: * README has been expanded. * supervisor

[announce] release 0.2.5 of rc-shim

I'm announcing the release of rc-shim v0.2.5, a small script that is useful for adding supervision to existing installations already using SysV-styled rc scripts. This is a very minor release. The following has changed. * now includes a primitive test script, useful for debugging shim behavior.

Re: A dumb question

On 5/1/2017 2:11 PM, Francisco Gómez wrote: And during the process, someone recently told me something like this. "It's old software. Its last version is from 2014. If I have to choose between a dynamic, bug-filled init like Systemd and a barely maintained init like Runit, I'd

[announce] release 0.3.0 of rc-shim

I'm announcing the release of rc-shim v0.3.0, a small script that is useful for adding supervision to existing installations already using SysV-styled rc scripts. The following has changed: * there is a testing script that ensures the shim will work with your shell. * confirmation that the shim

runit: is it still maintained and does it have a CVS repository?

I have a slightly older (version 2.1.2) mercurial repository at this address: https://bitbucket.org/avery_payne/runit It should not be far behind whatever is "current". That being said, unless you have a specific need for runit, s6 & friends are probably the way to go.

re: Incompatibilities between runit and s6?

I am guessing the differences will be subtle, and most of the general behavior you desire will remain the same. You may be able to get a way with a "sed 's/sv\ /s6-sv\ /' new-script-name" on some of your scripts; give it a try, what could it hurt? Also, for those systems not running CentOS, what

Re: [Announce] s6.rc: a distribution-friendly init/rc framework (long, off-topic)

> > I see that s6.rc comes with a lot of pre-written scripts, from acpid > to wpa_supplicant. Like Avery's supervision-scripts package, this is > something that I think goes above and beyond simple "policy": this is > seriously the beginning of a distribution initiative. I have no wish > at all

Re: The "Unix Philosophy 2020" document

For those readers that meet the following critieria: - Are unfortunate enough to only speak a single language, English; - And simply want to read an English version of the document; - Are (un)fortunately running a current Debian installation with missing Latex dependencies; Do