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 the
>
> 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 to
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
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.
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
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 rat
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.
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 settings
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 followi
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.
On
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
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
daemont
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
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 behavior is fairly consistent
I know some people will cringe a bit, but hear me out. There are still
lots of older installs out there, but none of them will give you a true
supervisor when you start a service. The scripts basically start the
daemon, make a note of its PID, and then assume it's still running.
What if you coul
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 up.
Some of the scripts on
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 afte
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 /et
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
grea
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
wo
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
leg
The supervision-scripts project isn't dead, although several Monty
Python fans might notice that it is pining for the fjords. Perhaps I
shouldn't have nailed it to the perch...
* As of March 3, 2016, the license has changed to the ISC license. Put
simply, if you pull the changes as of today's
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
Unless I am mistaken about what you are asking for, an
outdated/incomplete list of command equivalents can be found at
https://bitbucket.org/avery_payne/supervision-scripts/wiki/Comparison
It has not been actively maintained and there are a few gaps in it.
However, I think most of the informat
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 a
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
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
dow
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 th
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 2
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 t
Thank you. Thank you Thank you Thank you. You just solved a HUGE
problem for me.
I'm on Debian 7 with my home server, and Debian 7 comes with make <
4.0. Debian 8 does come with make >= 4.0, BUT, I do NOT want to update
to Debian 8 for reasons I won't go into right now. That means I'm stuck
Were vacations really meant to be a vacation, or just "time to fix
things that you haven't had time for"?
Done:
- - - -
+ New definitions: x2gobroker-authservice, x2gobroker-daemon.
+ Renamed the definition directory from /sv to /svcdef (service
definitions). This fixes a namespace issue wh
Thanks for all the tips. I've tried to apply the updates to the wiki
page as well as I can understand them. My apologies if I missed
anything. You and Laurent both received attribution as well.
On 7/12/2015 2:26 PM, Guillermo wrote:
On 7/13/2015 2:00 AM, Laurent Bercot wrote:
There's generally no use for the pgrphack/s6-setsid family of tools.
The mistake of auto-backgrounding is common, so the fghack family
of tools has easily identifiable uses, and it *is* a hack all right;
but I've never seen a daemon misuse sessions an
I wish I could say I have new definitions but work commitments are just
now slowing down. I do have some vacation time in the near future, and
perhaps a few new definitions will emerge from that. Right now, some
housekeeping and documentation is being addressed.
Done:
- - - -
+ A small comp
On 6/25/2015 2:28 PM, post-sysv wrote:
I'm honestly struggling to think of a practical use case for this,
though I may be lacking sufficient context.
It actually does have a use case, as I've run into it. (more on this in
a moment)
The case of a daemon breaking semantics of existing options
With yesterday's mention of the idea of a clearinghouse, the concept that
daemon options need to be versioned has been in the back of my head. Here
is an idea: versioned definitions. A crude example:
/etc/sv/sshd/envdir/DAEMON -> /etc/sv/sshd/envdir/current/DAEMON
/etc/sv/sshd/envdir/DAEMONOP
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
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 supervis
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 su
On 6/20/2015 3:58 AM, Lasse Kliemann wrote:
Gerrit Pape 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
(Public Domain files
On 6/18/2015 6:04 AM, Steve Litt wrote:
You or somebody had better document that clearly and simply.
I'm going to write up a document on the structure and contents of
definition directories, as used by supervision-scripts. However, I'm
going to try and approach it from an evolutionary approa
On 6/17/2015 1:47 PM, Colin Booth wrote:
/usr/libexec/getty This is true for at least freebsd and openbsd. I
don't have any net, dragonfly, or any of the derivatives to confirm
but I'd be surprised if they moved their getty location.
Thank you for the info.
This is actually a different name
On 6/16/2015 7:25 PM, Colin Booth wrote:
This not working is part of the curse of the maintainer and why I
think a big collection of definitions that isn't tied to individual
packages is a mistake. In this case for the examples, Laurent went
with assuming getty is in the path (though it'll still
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
> >
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
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
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
t maintainer?
I haven't seen Gerrit Pape on the list.
On Tue, Feb 17, 2015 at 4:49 PM, Buck Evan <mailto:b...@yelp.com>> wrote:
On Tue, Feb 17, 2015 at 4:20 PM, Avery Payne
mailto:avery.p.pa...@gmail.com>> wrote:
>
> On 2/17/2015 11:02 AM, Buck Evan wrote:
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
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.
https://bitbucket.org/ave
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 sque
On 6/8/2015 11:55 AM, Laurent Bercot wrote:
On 08/06/2015 16:00, Avery Payne wrote:
This is where I've resisted using sockets. Not because they are bad
- they are not. I've resisted because they are difficult to make
100% portable between environments. Let me explain.
I ha
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 infor
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 soc
The project has slowed and I do not have nearly the number of updates.
It's not dead, I tell you, it's merely resting. And no I didn't nail
its feet to the perch.
( for those that don't get the reference...
https://www.youtube.com/watch?v=4vuW6tQ0218 )
Done:
- - - -
+ New definitions: arpa
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 point
April has shown some steady progress, but it is slowing due to personal
commitments, namely a 2nd part-time job I've taken.Life is rather hectic
right now, but I am trying to keep an eye on the mailing list and my email.
The number of target definitions has been reduced. Several non-service
d
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 th
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.
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 this (having been up since 4am)
but I'll try to digest all the little bits and pieces into something.
Here we go...
First, I will quali
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.
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:
https://bitbucket.org/avery_
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".
On 4/28/2015 7:18 AM, bougyman wrote:
On Tue, Apr 28, 2015 at 8:38 AM, Avery Payne wrote:
I guess I don't know what this means, in practice. My child services
generally know about the
parent in their ./run script and the parent (sometimes) has to know
about the children in his
./finish s
On 4/28/2015 7:11 AM, Steve Litt wrote:
Hi Buck and Avery, What's "first-class support"? Is there a way, in
this thread, that the service behavior desired could be described,
instead of calling it "first class support"?
Then it's best that the term be abandoned. I've tried to sum up the
idea
On 4/28/2015 6:56 AM, bougyman wrote:
Currently runit-void uses /etc/runit/1, 2, and 3 for those stages,
with runlevels in /etc/runit/runsvdir, runsvdir watches
/run/runit/runsvdir/current, a symlink to /etc/runit/runsvdir/current.
Void linux is licensed under a 2 clause BSD style license, whil
On 4/22/2015 5:56 AM, bougyman wrote:
What more is needed and what would making this "first class" add or
improve upon? Tj
This question has been in the back of my mind for several days now,
giving it some off-and-on consideration.
The steps described are explicit and hard-coded into a serv
On 4/21/2015 3:08 PM, Buck Evan wrote:
On Tue, Apr 21, 2015 at 2:46 PM, Avery Payne <mailto:avery.p.pa...@gmail.com>> wrote:
Alternatively, are there general-purpose practices for
breaking this kind
of dependency?
Strange as it sounds, renaming
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. http://skarnet.org/software/
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 b
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
fdc
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 proj
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 system
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 De
March continues to be a busy month. Most of the work done was internal,
although a few definitions managed to make it out the door.
Done:
- - - - - - - -
+ New definitions: redis-server, ahcpd, mongodb, quake-server, famd,
gunicorn, mdadm
+ Revised definitions: rpcbind (now includes a ./chec
I'm asking because I went through some trouble to make my project
somewhat shell-agnostic. The intent is I can have separate support for
/bin/sh, execline, or some other scripting environment, should it be
desired. But it's only worth the effort if I can get off of the
sh-as-launcher dependen
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 would
On 3/10/2015 4:42 PM, Sarkis Varozian wrote:
Hi All,
I'm not sure why tai64 was chosen as the default here, I suppose that is a
question for another time,
I'm a newcomer here, so take what I say with a large grain of salt.
Near as I can tell, by using TAI64, you avoid date-time conversion
i
9:12 AM, John Albietz wrote:
Excited to hear about all these projects. Are there links to the projects where
I can find more information and also perhaps contribute? Thanks!
- John
On Mar 5, 2015, at 11:52 AM, Avery Payne wrote:
On 3/5/2015 2:03 AM, toki clover wrote:
Hello fellow Supervis
On 3/5/2015 2:03 AM, toki clover wrote:
Hello fellow Supervision Users,
I was busy lately working on Supervision-Scripts[1] Framework which grew
up to be quite complete and efficient with a very simple API.
Well done!
HISTORY:
First, I only started working on this after I discovered Avery P
A household move consumed most of January and February, so not much was
accomplished until later in the month. Un-boxing things tends to do that...
Done:
- - - - - - - -
+ New definitions: lighttpd, minissdpd, knockd, nscd.
+ Merged all run templates that utilize /bin/sh into a single, master
On 2/17/2015 11:02 AM, Buck Evan wrote:
I think there's only three cases here:
1. Users that would have gotten immediate failure, and no amount of
spinning would help. These users will see their error delayed by
$SVWAIT seconds, but no other difference.
2. Users that would have gotten immed
On 2/16/2015 5:08 PM, Buck Evan wrote:
My check is running from outside the docker, racing against runit.
I'm not clear on this. Am I understanding this correctly?
+ You have a service inside of a docker container
+ The service in the container is managed by runsv (which may or may not
be un
On 2/16/2015 3:56 PM, Colin Booth wrote:
If you are running the sv check within a dependent service's run
script that was spawned first, the script will fail and runsv will
respawn it, with the call eventually succeeding once the required
service is up.
If you're calling this from a daemon scri
On 2/10/2015 10:16 AM, Buck Evan wrote:
There's something preventing this message from being rendered:
http://skarnet.org/cgi-bin/archive.cgi?2:495
The one before it is fine:
http://skarnet.org/cgi-bin/archive.cgi?2:494
The one after is broken:
http://skarnet.org/cgi-bin/archive.cgi?2:496
B
On 2/10/2015 9:58 AM, Steve Litt wrote:
On Mon, 09 Feb 2015 19:22:26 +0100
Laurent Bercot wrote:
On 09/02/2015 18:50, Buck Evan wrote:
Is there truly no public access to the source control for runit?
If so, it's decidedly odd.
Not that odd.
Small projects don't really need an SCM. Most
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 com
On 1/22/2015 9:08 AM, post-sysv wrote:
On 01/22/2015 01:33 AM, Avery Payne wrote:
This brings to mind the discussion from Jan. 8 about "./provides",
where a defining a daemon implies:
* the service that it actually provides (SMTP, IMAP, database, etc.);
think of it as the "do
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 th
Ugh, sorry folks. I keep forgetting to change the address. Forwarded a
copy.
Forwarded Message
Subject:Re: Could s6-scscan ignore non-servicedir folders?
Date: Wed, 21 Jan 2015 11:40:58 -0800
From: Avery Payne
To: Olivier Brunel
On 1/21/2015 9:24 AM
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 be
and bring things down.
>
> Sent from my Windows Phone
> --
> From: Avery Payne
> 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.
>
>
ervice supervisor will execute the kill signal and bring things down.
>
> Sent from my Windows Phone
> --
> From: Avery Payne
> 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:
+ 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 cha
On Thu, Jan 8, 2015 at 3:08 PM, Luke Diamand 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 b
On Thu, Jan 8, 2015 at 9:23 AM, Steve Litt
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,
> right?
>
Both correct.
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
On Wed, Jan 7, 2015 at 6:53 PM, Laurent Bercot
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 script.
>>
>
> Here'
On Wed, Jan 7, 2015 at 7:23 AM, Steve Litt
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 out, and if the user
1 - 100 of 156 matches
Mail list logo
