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
M
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 - [EMAIL PROTECTED] 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
> Bug-cfengine@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-cfengine
_______________________________________________
Bug-cfengine mailing list
Bug-cfengine@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cfengine
