help-cfengine
[Top][All Lists]
Advanced

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

Re: checksum woes


From: Frank Ranner
Subject: Re: checksum woes
Date: Fri, 30 Jan 2004 00:18:53 +1100
User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

Tod Oace wrote:
A couple weeks ago I posted a message about trouble I'm having with
type=checksum network copies occasionally firing off when files have
not changed on the server.


I'd be VERY interested to hear if you solve this one.  I'm having the
EXACT same issue on one of my servers.  The difference in my case is
that I'm not using a checksum database of any kind.  All the checksums
get computed in real-time (server-side AND client-side).


Well that's disturbing/interesting. Yesterday I tried disabling the checksum database on the server side and have still been seeing the problems. So earlier today I disabled it on the client side and have seen a couple more cases of it since then. I'm not sure if it's slowed down any, but I'll know for sure tomorrow. I've been tracking one particular problem for the past couple weeks and have a good baseline.

I've been beating my head against the wall on this for a while.


I'm glad I'm not the only one. I guess.  :)

I'll try and capture and analyze more cfservd debug output soon.


I am having the same problem. However it is happening every time on some copies. Not only that, it then tries to save the file in /var/spool/cfengine, and finds an entry already there. It then recursively moves the saved files, and after a while I get files with multiple instances of _var_spool_cfengine at the beginning and umpteen .cfsaved extensions on the end.

I haven't looked into the problem yet. I only found it because 'locate' was segfaulting. Doing `locate '*' | tail` showed the segfault occuring after printing some of the overlong cfengine spool files.

It is interesting that the extraneous copies occur regardless of the checksum database. I suspected that the problem was related to the unsafe concurrent access to the checksum DB. It appears not. One of the files that gets copied every time is nedit. The destination is /usr/local/bin. There is definitely an entry for nedit in the checksum database. The database can be examined using db_dump with the -p option to show human readable output instead of hexified text.

Since the problem is solid for me I will try and duplicate it with the smallest config file I can manage. Then I should be able to do full debugging, trussing, network snooping, etc.

Regards,
Frank Ranner



reply via email to

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