[packagekit] Yum and locking

[Richard Hughes]

On Wed, 2007-10-17 at 14:09 -0400, Robin Norwood wrote:
> Richard Hughes <hughsient at gmail.com> writes:
> 
> > On Wed, 2007-10-17 at 13:37 -0400, Robin Norwood wrote:
> 
> >> The yum cli does locking right after configuration is setup (right about
> >> where we set the throttle above), and unlocks right after commands
> >> complete.  To duplicate these, we'd need to lock at about the time we
> >> set config.throttle, and unlock when the transaction is done - we'd
> >> probably also need some signal handling for when PK cancels an operation
> >> in progress.
> >
> > We could send yum something over stdin before we kill it, although
> > that's non-ideal.
> 
> I know pretty much nothing about python signal handling.  It might be
> nice to have an "I'm about to kill you" signal from PK, but I think
> ideally we should be able to catch SIGTERM and unlock before exiting.
> This is probably safest.

If you can catch SIGKILL or SIGTERM then that would be great. We can
signal something better (SIGUSR1?) a few 100ms before we do sigkill if
you like.

> >> I talked to Seth about this a bit today, and he agrees that we must do
> >> locking.  Even if an operation like a search might be considered 'read
> >> only', yum may update the cache if it is out of date for a repository -
> >> two actions running at the same time could do very bad things.  When an
> >> action is run on a repository, it will automatically update the cache if
> >> it is out of date.
> >
> > Is cache invalidation the only thing that needs to be protected? If so
> > this seems like using a sledgehammer to crack a nut.
> 
> Well, I'm not 100% sure, but I think 'corruption' is probably a more
> accurate term than 'invalidation'.  My understanding is you'd end up
> with multiple yum processes trying to write to the same cache file at
> the same time.  I don't think yum detects and corrects for that other
> than by dying if the cache doesn't parse.  We can probably catch
> whatever exception is thrown by a corrupt cache and regenerate the cache
> instead of just dying, however.

Okay, if yum is locked then we work from the cache read only - does that
work?

> I'll have to check to be sure.  I think my paragraph above about
> corruption is correct, though.

Why not just open the cache read only when the lock is held?

> So shall we go ahead and implement the nasty locking for now?

Lets see if there's an easy way to do this without locking.

Richard.