[packagekit] Yum and locking

[Robin Norwood]

Richard Hughes <hughsient at gmail.com> writes:

> 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.

Isn't SIGTERM more appropriate in this case?  I'm not really an expert,
though.  I thought the general idea was it's ok for apps to catch
SIGTERM and do some cleanup before exiting, but SIGKILL means die and
die right now.

>> 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?

I think the potential failure case looks like this:

o PK starts a 'read only' action without locking, with yum set to always
use the cache.
o yum commandline starts doing 'stuff' - installing rpms, say.  A cache
update is triggered.
o Who knows what the heck PK's yum gets back - possibly the cache files
are written to by the commandline yum while PK's yum is writing to them,
I dunno.

>> 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.

>From talking to Seth, I don't see one.  I'm happy to be proven wrong by
yum ninjas.  Jbowes?

-RN

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching