Bug 30276 - All network operations should be cancelable and must be canceled in some situations
Summary: All network operations should be cancelable and must be canceled in some situ...
Status: RESOLVED FIXED
Alias: None
Product: PackageKit
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Richard Hughes
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-20 04:24 UTC by Hedayat Vatankhah
Modified: 2010-09-23 06:33 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
packagekitd log during a non-cancelable operation (3.42 KB, application/x-bzip2)
2010-09-20 08:19 UTC, Hedayat Vatankhah
Details

Description Hedayat Vatankhah 2010-09-20 04:24:56 UTC
Network operations are very non-deterministic: the can finish almost instantly, or they can last for hours! Because of this, the user should be able to cancel these operations at which; sometimes because of a very slow internet connection, or maybe because of incorrect proxy settings (other conditions might occur too). Some (or maybe all) of these operations in PackageKit are not cancelable, and is a source of major frustration with package management system. Currently, usually the user will end up killing the PackageKit process to be able to continue his work (if he is lucky enough to know about killing the processes!). 

A real example: I'm connected to a very slow internet connection using my mobile phone. For whatever reason, I decide to lookup a package information in PackageKit. I start PackageKit and write the package name and press the find button. PackageKit goes into the "Starting" status and remains in it. This lasts for a few minutes and I think that it is going to connect to a repository and download its information. As I know that it is almost impossible with my current connection, I want to cancel the operation, but there is no way to do it. 
Then I close packagekit (gpk-application) and try using "yum -C info mypackage", but it says that PackageKit is still holding the lock. That's nonsense, I've closed the package kit window, so the search results are useless and I expect packageKit to release the lock immediately (or almost immediately) after I close the application. Finally, I end up killing packagekit daemon to be able to run my desired yum operation. 

The same situation could happen if you are in a network which uses proxy to connect to internet and you've not setup proxy settings in your system.

IMHO, it is a very important bug since it delivers a very bad impression about the whole package management system (I've seen it a lot). So, please take it seriously.

Thanks a lot
Comment 1 Richard Hughes 2010-09-20 04:40:49 UTC
(In reply to comment #0)
> IMHO, it is a very important bug since it delivers a very bad impression about
> the whole package management system (I've seen it a lot). So, please take it
> seriously.

Sure, I agree. It problem is you is an external process, and we try to sendit signals to make it quit. But if it ignores the signals, there isn't much we can do.

Well, actually that's a lie. We can use SIGKILL, but that has the tenancy to mess up your rpmdb. Which makes people kinda angry.

I would be interested to see the debug output. Could you do

killall packagekitd
(ensure yum is also not blocking)
/usr/libexec/packagekitd --backend=yum --disable-timer --verbose

and then try to start a transaction that 'wont' cancel.

Thanks,

Richard.
Comment 2 Hedayat Vatankhah 2010-09-20 08:19:38 UTC
Created attachment 38815 [details]
packagekitd log during a non-cancelable operation
Comment 3 Hedayat Vatankhah 2010-09-20 08:25:28 UTC
Thanks a lot for your consideration.

(In reply to comment #1)
> Well, actually that's a lie. We can use SIGKILL, but that has the tenancy to
> mess up your rpmdb. Which makes people kinda angry.

I think it is reasonable to expect that a backend should be safely cancelable/kill-able! during a network operation (considering the above argument). If it doesn't, I think this is a bug in the backend. There is no reason for yum to touch rpmdb while it is downloading something IMHO.
Comment 4 Richard Hughes 2010-09-20 08:31:52 UTC
(In reply to comment #2)
>TI:16:34:49	FI:pk-transaction.c	FN:pk_transaction_allow_cancel_cb,435
> - emitting allow-cancel 0

This looks wrong. Setting up the search should be cancellable, and there's an explicit self.allow_cancel(True) in the code (ln 451)

I'll try to find the problem now.
Comment 5 Richard Hughes 2010-09-20 08:43:24 UTC
Okay, yum, in all it's infinite wisdom, needs to download the packagelist repodata to get the list of enabled repos. I have no idea why it needs to do that.

commit da4e08f88e97c3663dc1a186b435af905ee25704
Author: Richard Hughes <richard@hughsie.com>
Date:   Mon Sep 20 16:40:31 2010 +0100

    yum: for some reason yum needs to download the packagelists at init, so mark the download as cancellable. Fixes fd#30276

There's a new release planned in just over a week, and this fix will be in that release. Thanks.
Comment 6 Hedayat Vatankhah 2010-09-20 09:19:40 UTC
Thanks :)
I've found another bug in canceling which I'll report as a separate bug.
Comment 7 Hedayat Vatankhah 2010-09-23 05:37:10 UTC
(In reply to comment #5)
> Okay, yum, in all it's infinite wisdom, needs to download the packagelist
> repodata to get the list of enabled repos. I have no idea why it needs to do
> that.
> 
> commit da4e08f88e97c3663dc1a186b435af905ee25704
> Author: Richard Hughes <richard@hughsie.com>
> Date:   Mon Sep 20 16:40:31 2010 +0100
> 
>     yum: for some reason yum needs to download the packagelists at init, so
> mark the download as cancellable. Fixes fd#30276
> 
> There's a new release planned in just over a week, and this fix will be in that
> release. Thanks.

Today I say that the cancel button is disable when packagekit status is "Downloading file lists". Is this also solved by this fix?
Comment 8 Richard Hughes 2010-09-23 06:29:48 UTC
(In reply to comment #7)
> Today I say that the cancel button is disable when packagekit status is
> "Downloading file lists". Is this also solved by this fix?

Yup.
Comment 9 Hedayat Vatankhah 2010-09-23 06:33:56 UTC
Great. Thanks again. :)


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.