[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible bug: parsing/scheduling of editfiles sections in multiple c

From: Tim Nelson
Subject: Re: Possible bug: parsing/scheduling of editfiles sections in multiple cfengine scripts
Date: Tue, 13 Sep 2005 12:05:43 +1000 (EST)

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 ( ), you need to test for foo and
bar to know which run you are in. If you don't test for them, then
the command will run both times. This makes sense, because you are
basically saying "i don't care when it runs".

In general I think this is true, but won't locking prevent the same
command from running twice?

Why would it? I certainly hope locks are released when the program
associated with it finishes. If you configure something to run in each
run of shellcommands, it should run in each run of shellcommands.
Anything else would be a serious bug.

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.


Kind Regards,
Tim Nelson
Server Administrator
P: 03 9934 0888
F: 03 9934 0899
E: address@hidden
WebAlive Technologies
Level 1, Innovation Building
Digital Harbour
1010 La Trobe Street
Docklands Melbourne VIC 3008

This email (including all attachments) is intended solely for the named 
addressee. It is confidential and may contain legally privileged information. If
you receive it in error, please let us know by reply email, delete it from your 
system and destroy any copies. This email is also subject to copyright. No
part of it should be reproduced, adapted or transmitted without the written 
consent of the copyright owner.

Emails may be interfered with, may contain computer viruses or other defects 
and may not be successfully replicated on other systems. We give no
warranties in relation to these matters. If you have any doubts about the 
authenticity of an email purportedly sent by us, please contact us immediately.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]