[Yum-devel] What to do about yum-updatesd?
James Antill
james.antill at redhat.com
Thu Jul 19 21:09:21 UTC 2007
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 <james.antill at redhat.com>
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.baseurl.org/pipermail/yum-devel/attachments/20070719/6bedc850/attachment.pgp
More information about the Yum-devel
mailing list