Red Hat Bugzilla – Bug 439721
Backend not killed/restarted after version update
Last modified: 2008-04-07 05:25:37 EDT
After updating my system, I got the attached notification complaining about
the backend not sending "status <value> signals for get-updates".
Created attachment 299645 [details]
Created attachment 299646 [details]
Second error from same update
After I closed that one, I then got a second complaint
"backend error: text contains a double"
Does this happen after a reboot? Is it possible you are running packagekitd
0.1.9 with the 0.1.10 tools?
This was a fresh install of F9 beta followed by updating from the pk-icon and
the message appeared at the end of the update.
So... maybe. Not sure how everything fits together and what would have been
new and old at what point of the update.
Yup, you're running the old daemon with the new tools. This shouldn't happen if
you have 0.1.10 installed when you update as the double space thing was nuked in
the daemon a while ago. Cheers.
Given that it's almost certain that we'll do an update of PackageKit during the
life of Fedora 9, shouldn't there be some handling of this case? Even if it's
just killing off packagekitd's on upgrade of the package? Although I guess that
runs into the problem of killing your update :-/
No, I think that's a sane request. We can just send packagekitd a "DaemonUpdate"
method call which will cause it to exit when all transactions have finished.
Then, all we need to do is call dbus-send in the packagekit rpm file. I guess
that is allowed?
Well, it could be a little weird -- think about the case where you're installing
to a chroot. You don't necessarily want to send a signal to the packagekitd in
Could packagekitd put an inotify watch on /usr/sbin/packagekitd?
What we do for desktop-data-engine is:
- Install a file $libdir/version and write the version in there in the %post
- Do an inotify watch on the file and if it changes to have some newer version
than the current running version, restart. (So there is an initial check after
establishing the inotify watch.)
I'm not sure if a pure inotify watch is completely correct ... it would trigger
if prelink got run, for example. And is also racy if the file gets changed on
startup before the inotify watch is in place. But maybe it's good enough.
I've added a watch on SBINDIR "/packagekitd" and proxied this to the client
programs. gpk-update-icon should now respawn when you do a package update, and
all the pending transaction have finished.
I've also made the first session instance of gpk-update-icon quit it's mainloop
only when the second instance is able to take over. In theory, the user should
never notice the session application was reloaded.