Laurent Bercot:
I'm of the opinion that packagers will naturally go towards what gives
them the less work, and the reason why supervision frameworks have
trouble
getting in is that they require different scripting and organization, so
supporting them would give packagers a lot of work; whereas
Avery Payne:
But from a practical perspective there isn't anything right now that
handles
dependencies at a global level.
Now you know that there is.
The nosh design is, as you have seen, one that separates policy and
mechanism. The service-manager provides a way of loading and unloading
John Albietz:
I wonder if this will help address a common situation for me where I
install a package and realize that at the end of the installation the
daemon is started using upstart or sysv.
At that point, to 'supervise' the app, I first have to stop the current
daemon and then
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
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 looking at a display of the various
definitions.
Why shouldn't they be
Here's an ugly hack that allows you do that using envdir:
set -a
eval $({ env; envdir ../.env env; } | grep -vF -e _= -e SHLVL= | sort | uniq -u)
set +a
Ugh, in the morning (almost) light it's even uglier than I thought,
because it won't work for values you *change* either, which could
be
@list.skarnet.org
Subject: 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
On Wed, 7 Jan 2015 14:25:28 -0800
Avery Payne avery.p.pa...@gmail.com wrote:
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.
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 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,
Paynemailto:avery.p.pa...@gmail.com
Sent: 1/6/2015 10:35 PM
To: Steve Littmailto:sl...@troubleshooters.com
Cc: supervision@list.skarnet.orgmailto:supervision@list.skarnet.org
Subject: Re: thoughts on rudimentary dependency handling
On Jan 6, 2015, at 4:56 PM, Steve Litt sl
Diamandmailto:l...@diamand.org
Sent: 1/7/2015 12:17 AM
To: supervision@list.skarnet.orgmailto:supervision@list.skarnet.org
Subject: Re: thoughts on rudimentary dependency handling
On 07/01/15 07:05, James Powell wrote:
The way I see it is this... Either you have high level dependency
On 07/01/2015 09:16, Luke Diamand wrote:
One small concern would be that it's not enough to simply signal a
dependency to be up - it needs to be actually running and working
before you can start the dependent service successfully. To take my
[least-]favourite example, you can't start autofs
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
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
On 07/01/2015 23:25, Avery Payne wrote:
The goal is the same but the emphasis has changed. This will be considered
a fall-back feature for those systems that do not have such a tool
available, or have constraints that force the continued use of a shell
launcher. It is the option of last
Down by default makes sense to me and will be a great feature.
I think that having it will require all services to have a 'down' script
that defines how to make sure that a service is actually down.
I wonder if this will help address a common situation for me where I
install a package and realize
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,
On 06/01/2015 18:46, Avery Payne wrote:
1. A service can ask another service to start.
2. A service can only signal itself to go down. It can never ask another
service to go down.
3. A service can only mark itself with a ./down file. It can never mark
another service with a ./down file.
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
important that you get it right. It's complex stuff that needs
planning and thought.
*
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
21 matches
Mail list logo
