[Top][All Lists]

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

Locking Issues (Fixed)

From: Scott Michael Koch
Subject: Locking Issues (Fixed)
Date: Tue, 14 Jun 2005 12:15:13 -0400
User-agent: Mutt/1.5.9i

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..):


dest=/etc/ r=inf timestamps=preserve
  $(local_config_root)/${os}/${osflav}/${osdist}/${osrel}/etc dest=/etc/ r=inf 
  $(local_config_root)/${os}/${osflav}/${osdist}/etc dest=/etc/ r=inf 
  $(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

For example: 

The first line will evaluate to:


...which will work fine, but create a lock file with the following name:


This is not a problem until the next line which evaluates to:


...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:


The error looks like this:

Checking copy from 
localhost:/var/cfengine/inputs/configs/linux/redhat_based/redhat_as/4/etc to 
Authentic connection verified
 ExpireAfter=120, IfElapsed=1
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

Have a good day,

Scott Koch                                    
CS Undergraduate & UTKCS System Administrator 
865-974-3840 / address@hidden                

Attachment: lock_fix_06142005.patch
Description: Text document

reply via email to

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