Bugzilla – Bug 185206
zmd drops services too early / does not revive dropped services
Last modified: 2006-07-10 04:32:16 UTC
zmd (at the 10.1 + updated package manager stack) level drops my ZYPP update sources. What I do: - boot laptop. network is down - login to KDE - zmd tries to refresh the update / zypp sources - this fails because it cannot resolve any host, including my uzpdate host. - zmd sees the zypp exception and marks the source as bad - network goes up (after I tell network manager to connect) - zmd refreshes it every hour, but never calls the zypp backend helpers, it just seems to remember it was bad once and never ever tries to start the refresh helper again Logfiles attached.
Created attachment 89539 [details] zmd-messages.log zmd-messages.log
Created attachment 89540 [details] zmd-messages.log.2006-06-14 zmd-messages.log.2006-06-14 here are the interesting parts... see the hourly refreshes... but there is nothing in the backend log for 21:36 and 22:36!
Created attachment 89541 [details] zmd-backend.log
this will likely happen on any Laptop and 10.1 and likely also SLED 10, since NetworkManager + bringing up the Network post-login is default there.
LANG=C rug sl --- No services found ---
perhaps ftp-1.gwdg.de was also not reachable yesterday evening. (it is not reachable as of 12 hours later, but I did not check yesterday). neithertheless the service should still tbe there and only marked as Inactive, if at all.
There is no such word "neitherthless". I guess you want to say "nevertheless= in spite of that; however".
Bug 156995 is almost certainly a dup of this one.
The zmd log indicates that the parse-metadata helper is exiting due to SIGIOT (whatever that is). So zmd is trying to refresh it, but zypp is having some sort of problem. -> Klaus
*** Bug 156995 has been marked as a duplicate of this bug. ***
See bug 183131 for info about the SIGIOT error message; it's an erroneous message caused by the helpers returning a negative value.
It is not a zypp problem I think. I straced zmd and it never starts parse-metadata after the first failed attempt. I think the ServiceManager never removes it from the busyServices hash for some reason.
The current version of libzypp-zmd-backend (rev 3635) adresses exactly the issue mentioned in the original comment and bug 183131. If a refresh is not possible, its logged as a warning to ZMD but operation continues with unrefreshed sources. Reassigning to ZMD because of comment #12 (ZMD never starts parse-metadata after the first failed attempt.)
Fixed in svn (r30550). ZMD was accidentally caching the result of the last parse-metadata run, which is why it wasn't running parse-metadata again (and explains why the logs seem to indicate that it did).
Verified fix with maw's 20060516 build.
Can users get the patch somewhere? Thanks in advance
will be released as roll-up update for 10.1 at some later time ... just like the first zypp patch.
*** Bug 190307 has been marked as a duplicate of this bug. ***
Are we certain this is fixed ? cf. unhappy journalist at: http://osnews.com/story.php?news_id=15103
he appears pretty confused in his article, mind.
The article refers to SLED, but he bug is still in SuSE 10.1 and no patch has been released (at least Zen didn't tell me). Is the patch coming?
we are still preparing this update for 10.1 a test repo is online, ftp://ftp.suse.com/pub/people/aj//10.1-packagemanagement-update-test/
Thank you! I'm installing it on my notebook.