On Tue, 13 Sep 2005, Tim Nelson wrote:
> I was under the impression that cfengine won't run the same thing
> twice in the same minute, as a protection device; I think you'd have to
> define the same command twice to get it to run twice.
Even then it won't run it twice; cfengine uses a conve
On Mon, 12 Sep 2005, Knut Auvor Grythe wrote:
On Mon, Sep 12, 2005 at 03:25:47PM -0500, Brendan Strejcek wrote:
So what you need to do is have a proper way of checking what
shellcommands run you are in. If you have the actionsequence (
shellcommands.foo shellcommands.bar ), you need to test for
On Mon, Sep 12, 2005 at 03:25:47PM -0500, Brendan Strejcek wrote:
>> So what you need to do is have a proper way of checking what
>> shellcommands run you are in. If you have the actionsequence (
>> shellcommands.foo shellcommands.bar ), you need to test for foo and
>> bar to know which run you are
Knut Auvor Grythe wrote:
> So what you need to do is have a proper way of checking what
> shellcommands run you are in. If you have the actionsequence (
> shellcommands.foo shellcommands.bar ), you need to test for foo and
> bar to know which run you are in. If you don't test for them, then
> the
On Mon, Sep 12, 2005 at 12:09:19PM -0600, Ed Brown wrote:
> I appreciate your effort to clarify the algorithms involved in
> actionsequence scheduling, but even the algorithms don't explain the
> actual behavior very fully.
It's actually quite simple. When you add "shellcommands.pre" to your
acti
On Mon, 12 Sep 2005, Ed Brown wrote:
> Luke,
>
> I appreciate your effort to clarify the algorithms involved in
> actionsequence scheduling, but even the algorithms don't explain the
> actual behavior very fully. Though there may be separate
> parsing/actionsequence placement passes for qualified
On Fri, 2005-09-09 at 09:55, Luke Kanies wrote:
> I haven't checked it in a while, but last time I did there was a
> relatively clear algorithm for scheduling. It had two stages:
>
> 1) All actions are scheduled in the order of first specification
> throughout the whole file. It doesn't matter
On Fri, 9 Sep 2005, Berthold Cogel wrote:
> If I define a actionsequence I expect it to be executed in the defined
> order.
I haven't checked it in a while, but last time I did there was a
relatively clear algorithm for scheduling. It had two stages:
1) All actions are scheduled in the order of
On Fri, 2005-09-09 at 07:11, Berthold Cogel wrote:
> If I define a actionsequence I expect it to be executed in the defined
> order.
Not unreasonable, but you you had better understand the limitations and
idiosyncracies of the syntax, which definitely aren't explained fully in
the documentation,
Ed Brown wrote:
My experience with actionsequence suggests two things:
1.) Declaring actionsequences in multiple files means that your
actionsequence is basically indeterminate. Actionsequences do not apply
per file. If you want control over your actionsequence, it's best to
declare it only on
My experience with actionsequence suggests two things:
1.) Declaring actionsequences in multiple files means that your
actionsequence is basically indeterminate. Actionsequences do not apply
per file. If you want control over your actionsequence, it's best to
declare it only once at the top leve
Hello!
We have seen here some strange behaviour in editfile sections in our
configuration. Somehow the internal task schedule gets mixed up.
Our Setup:
--
cfengine version: 2.1.15
OS version: Red Hat Enterprise Linux 3
update.conf General update mechanism (get c
12 matches
Mail list logo
