[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: rawhide report: 20070725 changes



Jeremy Katz wrote:
On Wed, 2007-07-25 at 16:31 +0200, Hans de Goede wrote:
Jeremy Katz wrote:
On Wed, 2007-07-25 at 03:33 -0400, Build System wrote:
New package yum-updatesd
	Update notification daemon
FYI -- this is a new and reworked yum-updatesd that should hopefully
help with some of the complaints that I have been had.  The *big* change
is that it's bit split into two pieces:
* The actual daemon.  This is small, listens to dbus, and doesn't ever
touch the rpmdb, etc.  Which should keep its memory footprint low.
* Helper process that's forked off to do actual update checks
(+downloads +installs if so configured).  Helper isn't threaded, which
should avoid some of the problems that have been cropping up.

People prodding and testing at this would be much appreciated; I'm
hoping to be able to push this to F7-updates at some point as well.
Bugs to bugzilla as usual

Does this also fix the issue where issuing any yum command wil fail while it is checking for updates? That is the no 1 reason for not to use yum-updatesd.

While the actual update check is going on, yes, things won't work.  But
that's just like if you run a yum command while another one is running.
The plus side is the thing holding the lock is a separate process that
dies and shouldn't just get hung up in thread-land

If it doesn't fix this, maybe the following is an idea:
-modify yum to detect if its yum-updatesd which is locking the current yum
  "database"

We could print out what the process holding the lock is easily enough I
guess if people think it would be a substantial help.


It would be a start, but see below.

-if it is yum-updatesd send it a signal to stop doing whats its doing, on which
  it will finish its current operation, and then release the db.

Can't really do this -- you can't just interrupt the metadata download
or package installation, etc.  But the time period for which it should
have the lock held should be able to be much more constrained now and if
it gets stuck, should be far more debuggable


With installation I agree, but yum-updatesd installing packages is not the default. And the meta datadownload needs to be done one way or the other, so the time lost while waiting for updatesd todo this is later won again.

-print: "waiting for yum-updatesdb to release the database"
-poll the database lock 2 times a second or so
-continue

This could also be done, but I'm not convinced that it's better than
just dropping you back to a prompt.  The difference is
  # yum update
    ...
    Lock is held by yum-updatesd-helper.  Spinning until released.  Hit
    ctrl-c to exit.
    ...
    ...
    ...
    Got it, carrying on

vs

  # yum update
    Lock is held by yum-updatesd-helper.
  # (wait here, do other tasks, etc)
  # yum update


There are 3 important differences:

1. Despite recent cleanups yum still isn't exactly instant, so usually I type "yum -y foo bar" and then switch away, only to find yum-updatesd was holding the lock when I look to see if yum is finished

2. There is no way to tell when yum-updatesd is finished so one still needs todo the polling manual, very anyoing. Or as I do just kill it and disable it in ntsysv (which AFAIK is not what we want).

3. I give various Linux labs, where students often need to install package foobar, because I try to make my labs excercises as real life as possible (debugging bugs in bugzilla for example) and thus not all needed packages are installed in advance. To you and me the difference is as you describe above, to them however its the difference between yum working as expect and remarks along the lines like: "Hans it isn't working" or "WTF does this error mean?", so to regular end users the difference is huge.

Regards,

Hans


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]