Bug 439721 - Backend not killed/restarted after version update
Backend not killed/restarted after version update
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Robin Norwood
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-03-30 19:01 EDT by Owen Taylor
Modified: 2008-04-07 05:25 EDT (History)
3 users (show)

See Also:
Fixed In Version: 0.1.10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-07 05:25:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Owen Taylor 2008-03-30 19:01:34 EDT
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 19:01:34 EDT
Created attachment 299645 [details]
Offending notification
Comment 2 Owen Taylor 2008-03-30 19:05:19 EDT
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 19:19:39 EDT
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-30 22:20:43 EDT
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 07:15:16 EDT
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 10:54:45 EDT
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 11:11:51 EDT
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 11:15:45 EDT
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 11:56:24 EDT
Could packagekitd put an inotify watch on /usr/sbin/packagekitd?
Comment 10 Owen Taylor 2008-03-31 12:15:38 EDT
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 18:24:01 EDT
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-03-31 21:35:49 EDT
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.