[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..):
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Locking Issues (Fixed),
Scott Michael Koch <=