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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
