Jonathan-
Looking naively at FnCallNow() in evalfunction.c, I believe you are correct in
your suspicion that cf-agent uses the start time as "now". Now, I say
"naively" because I am not that familiar with the Cfengine core code, and I
have a not-quite up-to-date version. For a long-running agent, this is
possibly a mistake, and I suggest the developers look at it (and either change
the code or the documentation, because it is not a true bug, it is merely a
confusing feature).
However, there being two sides to every coin (and sometimes three or four), I
notice that you are using mtime in your file_select body, which is the
modification time of the file. In this case, I think that you need to add
ctime into the mix. If you change the contents of a file, you change both the
ctime and mtime, but if you just change the permissions, you only change the
ctime. Do you want the time a file was changed? Or created/perm-changed?
The third side of the coin is that I don't see how either "bug" will cause your
problem. Unless you started cf-agent 30 days ago, your
currently-being-modified files should not be selected (and even though cf-execd
may be old, each run of cf-agent starts anew).
Finally, with the fourth side bringing us from coins to Euclidean solids, look
at your file_select body. What you have is legal and I think correct, but I
feel it would be clearer as what follows (changing the easy to miss negation,
and changing the mtime range):
body file_select date_pattern(age, pattern)
{
mtime => irange(0, ago(0,0,"$(age)",0,0,0));
leaf_name => { "$(pattern)" };
file_result => "leaf_name.mtime";
}
This might change the behavior, but I don't think so. At least I hope not.
But try it, and let me know...
-Dan
On Mar 4, 2012, at 7:16 AM, Jonathan CLARKE wrote:
> Hi everyone,
>
> I'm running into a funny issue, using a files promise to clean up files
> older than 30 days, that seems to catch very recent files (less than a
> few minutes old), or possibly files that are undergoing modifications as
> CFEngine runs.
>
> Here are my promises:
>
> bundle clean_www_archives {
> files:
> "/var/www/archives/"
> delete => tidy, # from cfengine_stdlib.cf
> file_select => date_pattern("30",
> "rudder-sources-.*~git[0-9]{12}\.tar\.bz2"),
> depth_search => recurse("inf"),
> classes => kept_if_else("archives_clean_ok",
> "archives_clean_repaired", "archives_clean_failed";
>
> reports:
> archives_clean_repaired:
> "/var/www/archives/ has been put in conformity with the
> deletion policy";
> }
>
> body file_select date_pattern(age, pattern)
> {
> mtime => irange(ago(0,0,"$(age)",0,0,0), now);
> leaf_name => { "$(pattern)" };
>
> file_result => "leaf_name.!mtime";
> }
>
> I know that a file was created named
> rudder-sources-2.4.0~alpha6~git201203040139.tar.bz2 at 01:39 on
> 04/03/2012 (the file handily has it's creation time in the name, very
> helpful in debugging this issue!). This is a reasonable sized archive,
> and can take several minutes to be filled, so we could assume that it's
> being written to continuously between 01:39 and 01:39+several minutes.
>
> During this time period, cf-agent is run, and I note this in the logs:
>
> Mar 4 01:41:25 jenkins cfengine[15847]: R: /var/www/archives/ has been put
> in conformity with the deletion policy
>
> Needless to say, the file has then disappeared (I know it was created
> because I have logs from the script that creates it to confirm that).
> Other files, identically named apart from the date-time component, are
> correctly handled (those younger than 30 days are kept, those older
> removed).
>
> Is it possible that CFEngine calculates "now" on startup, and the file
> is modified after that but before CFEngine checks it, and therefore
> CFEngine is thinking "oh this file is not between now and 30 days, it's
> newer, so I'll delete it"? Has anyone encountered something similar? Or,
> more importantly, does anyone have an idea for a workaround?
>
> In case it's relevant, this is cf-agent 3.2.0.
>
> Thanks for your help!
> Jonathan
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@cfengine.org
> https://cfengine.org/mailman/listinfo/help-cfengine
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
