Bug 439721 - Backend not killed/restarted after version update
Summary: Backend not killed/restarted after version update
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Robin Norwood
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-03-30 23:01 UTC by Owen Taylor
Modified: 2008-04-07 09:25 UTC (History)
3 users (show)

Fixed In Version: 0.1.10
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-04-07 09:25:37 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Offending notification (35.38 KB, image/png)
2008-03-30 23:01 UTC, Owen Taylor
no flags Details
Second error from same update (23.00 KB, image/png)
2008-03-30 23:05 UTC, Owen Taylor
no flags Details

Description Owen Taylor 2008-03-30 23:01:34 UTC
After updating my system, I got the attached notification complaining about
the backend not sending "status <value> signals for get-updates".

Comment 1 Owen Taylor 2008-03-30 23:01:34 UTC
Created attachment 299645 [details]
Offending notification

Comment 2 Owen Taylor 2008-03-30 23:05:19 UTC
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"

Comment 3 Richard Hughes 2008-03-30 23:19:39 UTC
Does this happen after a reboot? Is it possible you are running packagekitd
0.1.9 with the 0.1.10 tools?

Comment 4 Owen Taylor 2008-03-31 02:20:43 UTC
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.

Comment 5 Richard Hughes 2008-03-31 11:15:16 UTC
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.

Comment 6 Jeremy Katz 2008-03-31 14:54:45 UTC
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 :-/

Comment 7 Richard Hughes 2008-03-31 15:11:51 UTC
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?


Comment 8 Jeremy Katz 2008-03-31 15:15:45 UTC
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
the host.

Comment 9 Richard Hughes 2008-03-31 15:56:24 UTC
Could packagekitd put an inotify watch on /usr/sbin/packagekitd?

Comment 10 Owen Taylor 2008-03-31 16:15:38 UTC
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. 


Comment 11 Richard Hughes 2008-03-31 22:24:01 UTC
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.

Comment 12 Richard Hughes 2008-04-01 01:35:49 UTC
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.



Note You need to log in before you can comment on or make changes to this bug.