Kalu gets stuck on "Checking/updating in progress..." #70
Comments
|
(kalu:20654): Gtk-CRITICAL **: 08:00:52.804:
gtk_status_icon_set_from_icon_name: assertion 'GTK_IS_STATUS_ICON
(status_icon)' failed
I believe this is completely unrelated, and should be fixed on branch
next in github BTW.
Occasionally, kalu will then give an error message saying that it
fails to connect, and then will reset. Mostly however, it stays stuck
indefinitely. I have to SIGKILL, and restart kalu. I'm happy to
provide more debugging information, but I'm not sure how to go about
this.
Well, if the icon is still flashing as you way, clearly kalu isn't
crashed/stucked or anything. It sounds like there's a connection that
it's waiting for, and for some reason never dies/times out... not sure
why though.
If you could reproduce it while running it with --debug it might
indicate at least during which check(s) it happens (RSS/news, upgrades,
AUR...) but really they should all fail/time out at some point.
|
|
Thank you for the quick response.
Brilliant. Thank you.
Ah yes, fair enough. My language was imprecise. Normally, SIGTERM can terminate kalu. However, when I described kalu as "stuck" above, I need SIGKILL to terminate it.
I'll try to catch it with this flag, and report back here. |
|
Ah yes, fair enough. My language was imprecise. Normally, SIGTERM can
terminate kalu. However, when I described kalu as "stuck" above, I
need SIGKILL to terminate it.
Ah right, but that would be by design though, because kalu basically
ignores SIGINT & SIGTERM when it is busy, i.e. running checks or the
updater.
I've pushed a branch abort-checks on github, changing how this is done.
Now SIGINT will abort any running checks (but not cause kalu to exit),
and SIGTERM will abort any running checks and then exit. Note that both
are still basically ignored when the updater is running though.
I've also added a menu item on top of the menu, when checks are
running, to abort them. So, if you can try kalu from this branch, when
it gets "stucked" you can try aborting (send SIGINT or use the new menu
item) and see if that helps. (If not, it would still be good to have
the --debug output, again to get a sense of when this happens.)
I need to add however, that due to a little bug in pacman (libalpm)
once you've aborted checks (doesn't matter how, the menu item simply
raises SIGINT anyways) you'll need to exit kalu & restart it, otherwise
ALPM will just abort for any & all new downloads due to that bug.
Or, you can buid pacman with the patch[1] to fix the issue ;)
Cheers,
[1]
https://lists.archlinux.org/pipermail/pacman-dev/2018-October/022861.html
|
Brilliant, thank you for that! Also, kalu stalled again. It looks like it happened this morning, 12 hours ago, so it's definitely beyond a plausible timeout (although the computer was suspended for most of that). The output is below. I stripped out all of the I checked my logs, and the computer resumed from suspend at 7:43:31, and then slept again at 8:11:54. I'd say the time at which kalu failed, 14 seconds after suspend, is likely when the VPN turns on again from experience. |
|
I checked my logs, and the computer resumed from suspend at 7:43:31,
and then slept again at 8:11:54. I'd say the time at which kalu
failed, 14 seconds after suspend, is likely when the VPN turns on
again from experience.
From the log, at 07:43:31 (so when you resumed) kalu starts its checks.
The news are downloaded fine, the updates are also checked without
issue, then comes the AUR check.
A first query is done and results downloaded in a few seconds, then a
second query is done and... nothing. That's 14 seconds after resume, so
when you suspect your VPN to turn on, right?
So maybe your VPN is changing your configuration (routing, etc) and
somehow breaks kalu.
I've pushed some changes on branch abort-checks, during such downloads
kalu should now abort/timeout if the speed goes under 1b/s during 10s
-- so hopefully with this, after about 10s it should now timeout.
Please rebuild kalu from the latest abort-checks and let me know if
that changes anything; Thanks.
Cheers,
|
|
Thank you again.
Correct.
Yes, that is my interpretation also.
Done. I'll report back when I notice anything again. It's intermittent, and I guess I'm looking for the lack of an error, so if I take a while then it's probably a good thing. I can report that the |
|
I think it's working. I resumed from sleep, then got a notification ~5 minutes later. I'm guessing this is the new timeout? |
|
I'm guessing this is the new timeout?
Yes, looks like that would be it indeed.
So this should be fixed now, good. Thanks!
|
|
Thank you! I appreciate your excellent support once again! |
jjk-jacky
added a commit
that referenced
this issue
Oct 15, 2018
Trying to avoid too slow downloads - or connections that hang without any transfer at all - by forcing a timeout if the speed goes under 1 byte/s during 10s. Thanks to protist; Fixes #70
|
I just noticed that this issue has appeared again. Unbeknown to me, Kalu was stuck for a few days. I'm happy to troubleshoot and check times again, but I just thought to mention it here just in case it was an obvious change in the code. |
|
Well, I'm not sure if I've caught it in the terminal, but I'll post this up anyway. (Please note I'm still getting the GTK errors.) A few things to note.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A few times a week, kalu gets stuck. The icon is flashing, and hovering shows a pop-up saying
There is nothing in the terminal, except the "normal" GTK errors:
Occasionally, kalu will then give an error message saying that it fails to connect, and then will reset. Mostly however, it stays stuck indefinitely. I have to SIGKILL, and restart kalu. I'm happy to provide more debugging information, but I'm not sure how to go about this.
Possibly relevant, I use a VPN via NetworkManager. After resuming from suspend, I have normal network connectivity after a few seconds, but the VPN then takes another few seconds to connect. This creates problems for things like Firefox. If I connect to a web page after initial connectivity, loading can stall after the VPN turns on. I'm unsure if kalu has similar issues if it is checking for updates when the VPN turns on. Either way, I presume that kalu's timeout should fix this in theory.
I'm using kalu-kde 4.3.0-1 from the AUR, which is kalu compiled with
--enable-status-notifierand depending onstatusnotifier. I'm using KDE Plasma, and my Arch install is up-to-date. I've been experiencing this issue for a few months now.The text was updated successfully, but these errors were encountered: