[packagekit] Yum and locking

[Tim Lauridsen]

Robin Norwood wrote:
> 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
>
>   
There is no way without locking, i will be a very dangerous game to play.
I have added locking to all yum commands except the search-*, they are 
running in cache only, so they should not mess up any systems.
The still is needing some signal catching to work with the abort case.

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20071018/44c9e9e9/attachment-0002.htm>