Locking Issues (Fixed)

[Scott Michael Koch]

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

-- 
==============================================
Scott Koch                                    
CS Undergraduate & UTKCS System Administrator 
865-974-3840 / address@hidden                
http://www.cs.utk.edu/~koch                     
==============================================

lock_fix_06142005.patch
Description: Text document