Hello, On Tue, 26 Mar 2013 13:42:04 -0400 (EDT) [email protected] wrote:
> Every so often, parallel invocations of ifup (for example, by Upstart) > will clobber each other's tmpstatefile in update_state(), causing the > loser(s) to fail. > update_state() opens the statefile, gets a F_SETLKW lock on it, opens > a tmpfile, filters the contents of the statefile into the tmpfile, > closes the tmpfile, then renames the tmpfile over the statefile. > Once the rename() happens in one instance of ifup, any other blocked > instances are waiting around to lock a file that no longer exists in > the filesystem. Overlap enough instances of ifup just right and you > have them all locking different copies of statefile, which then > doesn't prevent any of them from rename()ing tmpstatefile out from > underneath the others, thus causing their own rename()s to fail with > ENOENT. Hi, I was investigating this issue... This looks interesting, but... well, from what I see in the code, ifupdown currently fails as soon as it finds the lock is already taken, it doesn't wait at all. Or am I wrong? -- WBR, Andrew
signature.asc
Description: PGP signature
