[Top][All Lists]

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

Re: Locking Issues (Fixed)

From: Mark Burgess
Subject: Re: Locking Issues (Fixed)
Date: Sun, 09 Oct 2005 17:40:48 +0200

I used ton think 255 might be too much, since a node name cannot exceed
this length. I increased to 200, which gives a margin. I was afraid
that, if we make it more than that, we might start to get errors about
not being able to create the lock.

Now I remember why I moved this into berkeley db! So .. now it's okay


On Tue, 2005-06-14 at 12:15 -0400, Scott Michael Koch wrote:
> We have found out what was causing the strange locking issues that
> Markus mentioned in his post 06/09/2005 on the help list. We have 
> sections of config files that look like the following for  
> (etc, root, sw, etc..):
> copy:
>   $(local_config_root)/${os}/${osflav}/${osdist}/${osrel}/${host}/etc 
> dest=/etc/ r=inf timestamps=preserve
>   $(local_config_root)/${os}/${osflav}/${osdist}/${osrel}/etc dest=/etc/ 
> r=inf timestamps=preserve
>   $(local_config_root)/${os}/${osflav}/${osdist}/etc dest=/etc/ r=inf 
> timestamps=preserve
>   $(local_config_root)/${os}/${osflav}/etc dest=/etc/ r=inf 
> timestamps=preserve
>   $(local_config_root)/${os}/etc dest=/etc/ r=inf timestamps=preserve
>   $(local_config_root)/etc dest=/etc/ r=inf timestamps=preserve
> However, because these path names evaluate to such long path names, we
> run into problems with lock files being created with names that are too
> general. 
> For example: 
> The first line will evaluate to:
> /var/cfengine/inputs/configs/linux/redhat_based/redhat_as/4/mookie/etc/ 
> ...which will work fine, but create a lock file with the following name:
> PutLock(last.cfagent_conf.100.thoth.copy._var_cfengine_inputs_configs_linux_redhat_based_re__etc);
> This is not a problem until the next line which evaluates to:
> /var/cfengine/inputs/configs/linux/redhat_based/redhat_as/4/etc/
> ...and when it tries to create a lock file for this statetment, it
> already exists and causes that copy to fail. This fails because it also
> tries to create a lock like this:
> PutLock(last.cfagent_conf.100.thoth.copy._var_cfengine_inputs_configs_linux_redhat_based_re__etc);
> The error looks like this:
> Checking copy from 
> localhost:/var/cfengine/inputs/configs/linux/redhat_based/redhat_as/4/etc to 
> /etc
> Authentic connection verified
> GetLock(copy,_var_cfengine_inputs_configs_linux_redhat_based_re__etc,time=1118761915),
>  ExpireAfter=120, IfElapsed=1
> GetLastLock()
> cfengine:thoth: Another cfengine seems to have done 
> copy._var_cfengine_inputs_configs_linux_redhat_based_re__etc since I started
> The way I got around this is to change the snprintf statement to use
> more characters to build the lock name. The new snprintf statement looks
> like this:
> Line 2458 of do.c on version 2.1.14 (line 2460 of do.c in 2.1.15):
> /*Increased string size of path from 50 to 255 to ensure that the IDs are 
> unique - address@hidden 06/14/05 */
> snprintf(vbuff,CF_BUFSIZE,"%.255s.%.50s_%.50s",path,destination,server); /* 
> Unique ID for copy locking */
> Not sure is this is the best way to fix this, but it fixes our problem
> and it is fairly clean. There are couple other places where this
> limitation of the snprintf statment *could* cause a problem, but we have
> not run into it yet. 
> Patch is attached (lock_fix_06142005.patch). Or from
> http://cs.utk.edu/~koch/cfengine_lock-fix_06142005.patch
> Have a good day,
> -Scott
> _______________________________________________
> Bug-cfengine mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-cfengine

reply via email to

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