Aaron Griffin a écrit :

On Tue, Jul 21, 2009 at 5:25 PM, Firmicus<Firmicus@gmx.net> 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