On Wed, 21 Oct 2020 13:26:25 +
"Laurent Bercot" wrote:
> "A is ready" means:
>- if A is a oneshot: when the script has completed
>- if A is a longrun:
> * if there is a notification-fd file in the service definition
> directory: when the daemon has notified readiness
> *
Hi Amaresh,
As long as service B depends on service A, A and B will never start
in parallel; B will always start when A is ready.
"A is ready" means:
- if A is a oneshot: when the script has completed
- if A is a longrun:
* if there is a notification-fd file in the service
On 21.10.20 12:10, Amaresh Kotekal wrote:
Hi Team,
I have some doubt on dependencies file in S6.
Secnario 1:
1. A & B are one shot services in a s6-rc bundle. Service B is dependent on
A. ( added in dependency file).
2. I think Service B will start after the completion of service A ( A th
El mié., 21 oct. 2020 a las 7:10, Amaresh Kotekal escribió:
>
> Secnario 1:
> 1. A & B are one shot services in a s6-rc bundle. Service B is dependent on
> A. ( added in dependency file).
> 2. I think Service B will start after the completion of service A ( A then
> B, in serial manner ) is it
Hi Team,
I have some doubt on dependencies file in S6.
Secnario 1:
1. A & B are one shot services in a s6-rc bundle. Service B is dependent on
A. ( added in dependency file).
2. I think Service B will start after the completion of service A ( A then
B, in serial manner ) is it correct ?
Well, I found this to be fairly over-simplified. If all members of the
disjunction are longruns, using s6-svwait is OK; however this is not
directly extensible to oneshots and bundles. Nevertheless, I think the
idea of using a separate command to wait for the disjunction is still
architecturally
That would be much cleaner. Thanks :)
On Tue, May 02, 2017 at 02:40:56PM +, Laurent Bercot wrote:
> Probably not. If anything, I'll think about the use of s6-svwait > oneshots
> a bit more, and if I assess it's the correct, or as correct as it gets,
> way to implement disjunctions, I'll
By the way, if this change is done in s6-svwait, perhaps the s6-rc FAQ
can mention that dynamic (i.e. without using s6-rc-update manually)
virtual dependencies can be implemented using s6-svwait oneshots?
Probably not. If anything, I'll think about the use of s6-svwait
oneshots
a bit more, and
Yes, I think this is the correct behaviour: if the user does not want
it, the warnings can be somehow filtered; on the other hand, there would
not be a trivial way to know such failures if the user wants it but
there is no warning in the first place.
By the way, if this change is done in
Nevertheless, s6-svwait -o seems to also fail if some failure occurs
before the wanted state is reached, eg. one `dnscrypt-proxy' instance
reporting permanent failure before another one comes up successfully.
So we might need to add an option to ignore such failures.
Yes, that's a good point.
I just realised that we can set up a oneshot for the disjunction with
its dependencies being the intersection of the dependencies of all
services in the disjunction, with the `up' and `down' being something
like `s6-svwait -o -[ud] srv1 srv2 ...' ([ud]: `u' for `up', `d' for
`down'), so perhaps no
What about a `dnsmasq' service depending on serveral `dnscrypt-proxy'
instances for failover, and can start when any of the instances become
ready?
On Tue, Sep 29, 2015 at 06:00:40PM +0200, Laurent Bercot wrote:
> On a theoretical level, I tend to agree; and I will definitely
> think about
On Tue, Sep 29, 2015 at 10:46:02AM +0800, Casper Ti. Vector wrote:
> * "opportunist" dependencies:
After some more thought, I found one may as well supply a `mandatory'
and `opportunist' file for each service, and write a preprocessor
program to auto-generate the `dependencies' file, like this
On Tue, Sep 29, 2015 at 09:29:23PM +0800, Casper Ti. Vector wrote:
> tr -s ' ' '\n' | grep -xF "$2" | cat "$1" -
Should be:
tr -s ' ' '\n' | grep -xFf "$2" | cat "$1" -
--
My current OpenPGP key:
4096R/0xE18262B5D9BF213A (expires: 2017.1.1)
D69C 1828 2BF2 755D C383 D7B2 E182 62B5 D9BF 213A
On 29/09/2015 04:46, Casper Ti. Vector wrote:
Nevertheless, I think it can be helpful to also support "opportunist"
dependencies: if said service is not enabled, it is silently ignored;
if said service is enabled, the dependency on it is considered in the
dependency resolution
Sorry, but please allow me to append my previously forgotten conclusion:
"Make it simple, but not over-simple".
On Tue, Sep 29, 2015 at 10:28:30PM +0800, Casper Ti. Vector wrote:
> Sorry again for my possibly irritating language. Hope these make sense.
--
My current OpenPGP key:
I see. I agree that the typical use case of this feature is almost
limited to the `eth0'/`wlan0' scenario and cannot think of any other
concrete use case that is compelling.
Nevertheless, I still think this make s6-rc "incomplete"
mechanism-wise (sorry if that appears like insulting):
On 29/09/2015 16:28, Casper Ti. Vector wrote:
as a mechanism, the online virtual is demanding to implement
in an RC system, but might be even much more difficult to implement
elsewhere. More than that, this mechanism fits naturally into an RC
system, so it is architecturally a reasonable part
[Just accidentally sent as private mail; reposting verbatim.]
I'm glad that possibility still exists. Thanks :)
On Tue, Sep 29, 2015 at 06:00:40PM +0200, Laurent Bercot wrote:
> I just compromised here in the name of practicality. It's definitely
> a possibility of evolution for s6-rc if it
19 matches
Mail list logo
