Aaron Griffin a écrit : > On Tue, Jul 21, 2009 at 5:25 PM, Firmicus<[email protected]> wrote: > >> Added some output to the lock/unlock functions to see if it helps >> illustrate the issue better >> >> I also fiddled with the cleanup function in db-update a bit, so it >> only calls repo_unlock on an error. Didnt commit the changes, but lets >> see if that helps >> >> >> >> I think I fixed it. The thing is that through >> trap cleanup 0 >> the function cleanup() is called automatically at the end of the script. >> And since cleanup in turn calls >> repo_unlock $reponame $current_arch >> the latter fails because $current_arch is "x86_64" and we have already >> unlocked each repo before the end of the for loop, resulting in a spurious >> error message. >> Replacing repo_unlock by >> rm -f $TMPDIR/.repolock.$reponame.* >> in cleanup() solves this. (It might be actually better to have a function >> delete_repolocks() in db-function that does this...) >> > > Actually, the point of repo_lock/unlock was to do just this. The > problem with this change is that repo_lock, in theory, may not always > make a file like that (we may decide, at a later date, to "lock" the > repo some different way). The lock/unlock pairs should be done on each > repo, and needs to be there for the error case. >
I perfectly agree on that. > I made a change to simply remove the trap after the looping is done. > Fine. > I'll commit the rest of the patch too > > Thanks. The scripts now work flawlessly :) I think you can now safely remove the DBG messages from db-functions. F
