On Thu, 2007-07-19 at 15:23 -0400, Jeremy Katz wrote: > To anyone who's been watching bugzilla, yum-updatesd continues to get > beat up on quite a bit. Everything from resource usage, to just sitting > and hanging, to failures and other things. > > seth, jbowes and I sat down last week with a helpful moderator (wwoods) > to try to figure out a way to improve the status quo. We covered a lot > of ground starting with making yum-updatesd go back to just having a > cron job kicking off yum going all the way to making yum-updatesd a > massive service used by all the GUI tools for their installation needs. > > In the end, we reached a bit of a middle ground. A lot of the problems > seem to be related to the fact that yum-updatesd currently gets into > states where it's hung. A lot of this felt like it could be resolved if > we could a) stop using threads and b) have the process accessing the > rpmdb + yum metadata actually _exit_. From there, we came to the idea > of splitting things up into two pieces. > 1) yum-updatesd. Daemon that sits on dbus brokering off requests > 2) yum-updatesd-helper. Helper process that gets forked off to do > everything with the rpmdb. > > After a couple days of just seeing if it's feasible, I've got something > now that looks like it works and fulfills most[1] of our more full list > of requirements[2].
Cool, I wondered about going this route ... but wasn't sure what you're reaction would be. One thing I had considered when I'd thought about it was having three stages: 1. Long running C daemon. 2. python helper to get current list of updates. 3. python helper to install some/all of current updates. ...mainly because this seemed like it would integrate better with the panel applet and it might make it easier to implement a couple of features. > To get it, you can currently do > git clone http://katzj.fedorapeople.org/git/yum-updatesd.git > or grab the packages (epoch 1 so they upgrade what's in yum) from > http://katzj.fedorapeople.org/repos/yum-updatesd > > Thoughts, comments, testing appreciated. . It seems kind of ugly to have the daemon spawn a short lived helper and then get it's data back via. dbus. . I think you want the top level gamin monitoring to add new directories to the watch list, no? . So, I might be wrong, but I don't see a call to invalidate_cache() after an update (emitUpdateApplied doesn't seem to do that in the daemon part). But maybe I'm just missing something here. > I think that post yum 3.2.2, > we want to think about just removing yum-updatesd from yum itself and > pointing people to use this new version instead. Sounds good. > [1] The big thing missing is that the daemon side is still written in > python because that's faster to do. The advantage of moving it to C > will be a lower memory footprint which is probably worth it for a system > daemon. But that can also be a second step. If you don't want to do it, I can take a look at this bit as I've still written more C than python this year :). -- James Antill <[EMAIL PROTECTED]> Red Hat
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
