[Top][All Lists]

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

copy locking problem up to 2.1.1, patch included

From: Eric Sorenson
Subject: copy locking problem up to 2.1.1, patch included
Date: Tue, 20 Jan 2004 10:16:55 -0800 (PST)

Hi, attached is a naive patch to lock.c against 2.1.1. It fixes
a problem I discovered using 'singlecopy' to do most-specific
file copies from a repository as illustrated below. 

## BEGIN snippet
    singlecopy = ( on )
    AllowRedefinitionOf = ( role )
    AddInstallable = ( dmz )

    dr = ( /export/home/local/cfengine2 )
    fs = ( sinistar.domain.com )

    any:: role = ( default )
    dmz:: role = ( dmz )

    # the following are various hostnames of machines in the DMZ
    dmz = ( nft nmx ns1 )

    $(dr)/etc/mail/sendmail.cf.$(host) server=$(fs) dest=/etc/mail/sendmail.cf 
        owner=root group=root backup=false type=sum
    $(dr)/etc/mail/sendmail.cf.$(role) server=$(fs) dest=/etc/mail/sendmail.cf 
        owner=root group=root backup=false type=sum
## END snippet

The idea is that in the repository there are several sendmail.cf, as

This means that 'nmx' will get its own special sendmail.cf, the
rest of the machines in the DMZ will get sendmail.cf.dmz, and
everyone else gets sendmail.cf.default.

The problem arises when there isn't a 'sendmail.cf.$(host)' for 
a given client's value of $(host). The output of 'cfagent -v' on host
'joust' (which ought to get sendmail.cf.default) shows:

Checking copy from 
sinistar:/export/home/local/cfengine2/dist/etc/mail/sendmail.cf.joust to 
cfengine:joust: Server returned error:  Host authentication failed. Did you 
forget the domain name or IP/DNS address registration (for ipv4 or ipv6)?
cfengine:joust: Can't stat 
/export/home/local/cfengine2/dist/etc/mail/sendmail.cf.joust in copy
Checking copy from 
sinistar:/export/home/local/cfengine2/dist/etc/mail/sendmail.cf.default to 
cfengine:joust: Nothing scheduled for 
(0/1 minutes elapsed)

It doesn't copy sendmail.cf.default because there's a lock in place
for that target file, even though the source file is different. If
the name of the lock was longer, I suppose it would succeed; but from
do.c:2470 we see

    snprintf(VBUFF,bufsize,"%.50s.%.50s",path,destination); /* Unique ID for 
copy locking */

The full path to the source file exeeds 50 characters before it diverges,
so the lock that is checked for sendmail.cf.joust doesn't differ from the
lock grabbed for sendmail.cf.default. A second later when that copy is 
supposed to happen the lock is still active ("0/1 minutes elapsed") so
it's gets skipped. I'm not sure what's going on in the 
ReleaseCurrentLock() calls, but running 'cfagent -K' doesn't exhibit
the behavior.

One fix might be to increase the path length of the lockfile name, but
I don't think my paths to the repository and files therein are really
excessive or out of the ordinary, and this still leaves a hidden 
landmine for the future.

What the attached patch does instead, then, is move the 'if(cfstat...)'
stanza at do.c:2481-2489 up above do.c:2470. If the cfstat doesn't
suceed, the copy isn't going to happen so it doesn't seem necessary
to grab a lock.  Again, this is somewhat naive, but it does work.


    Eric Sorenson - EXPLOSIVE Networking - http://explosive.net

Attachment: cfengine-copylock.patch
Description: Text document

reply via email to

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