If I run gpk-application, without a configured proxy on /etc/yum.conf, and I'm on a network that needs a proxy, I see a list of tasks in the notification area, such as: Getting a list of repositories (Starting). However, it never finishes and I can't cancel it. This probably can be triggered with netem (tc).
Very easy to reproduce in fact: % sudo yum clean all % sudo tc qdisc add dev eth0 root netem loss 100% % gpk-application * Type 'foo' and click 'Find' Bang. PackageKit doesn't work any more. This makes it work again: % sudo tc qdisc delete dev eth0 root But of course that doesn't help when the pending operation was done with bad proxy settings, and that operation would hang forever. The solution would be to timeout.
Does using yum on the command line timeout? The bug sounds like something in yum blacking PK, not the other way around.
(In reply to comment #2) > Does using yum on the command line timeout? The bug sounds like something in > yum blacking PK, not the other way around. Shouldn't PK be resilient to buggy backends?
(In reply to comment #3) > (In reply to comment #2) > > Does using yum on the command line timeout? The bug sounds like something in > > yum blacking PK, not the other way around. > > Shouldn't PK be resilient to buggy backends? Sure, but when it hands a task to a backend, there's not much it can do, short of killing the process.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Does using yum on the command line timeout? The bug sounds like something in > > > yum blacking PK, not the other way around. > > > > Shouldn't PK be resilient to buggy backends? > > Sure, but when it hands a task to a backend, there's not much it can do, short > of killing the process. SIGINT?
Apparently this is never going to be fixed.