<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Robin Norwood wrote: <blockquote cite="mid:xf43aw9a6xi.fsf@solitude.devel.redhat.com" type="cite"> <pre wrap="">Richard Hughes <a class="moz-txt-link-rfc2396E" href="mailto:hughsient@gmail.com"><hughsient@gmail.com></a> writes: </pre> <blockquote type="cite"> <pre wrap="">On Wed, 2007-10-17 at 14:09 -0400, Robin Norwood wrote: </pre> <blockquote type="cite"> <pre wrap="">Richard Hughes <a class="moz-txt-link-rfc2396E" href="mailto:hughsient@gmail.com"><hughsient@gmail.com></a> writes: </pre> <blockquote type="cite"> <pre wrap="">On Wed, 2007-10-17 at 13:37 -0400, Robin Norwood wrote: </pre> </blockquote> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">We could send yum something over stdin before we kill it, although that's non-ideal. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">Okay, if yum is locked then we work from the cache read only - does that work? </pre> <blockquote type="cite"> <pre wrap="">I'll have to check to be sure. I think my paragraph above about corruption is correct, though. </pre> </blockquote> <pre wrap="">Why not just open the cache read only when the lock is held? </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">So shall we go ahead and implement the nasty locking for now? </pre> </blockquote> <pre wrap="">Lets see if there's an easy way to do this without locking. </pre> </blockquote> <pre wrap=""> >From talking to Seth, I don't see one. I'm happy to be proven wrong by yum ninjas. Jbowes? -RN </pre> </blockquote> 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 </body> </html>