Re: [Pan-users] Tasks get stuck

[Duncan]

Graham Peter Davis posted on Mon, 13 Jun 2011 12:22:28 +0000 as excerpted:

> On Mon, 13 Jun 2011 11:52:03 +0000, Graham Peter Davis wrote:
> 
>> I select "Get new headers in subscribed groups" and it does a few and
>> then stops at 0/17. I've tried cancelling all the tasks and trying
>> again, selecting all groups and "get new headers in selected groups",
>> closing down and restarting. Presumably, similar to when TB gets its
>> knickers in a twist, I've got to edit/delete file(s) (in .pan2) but
>> which one(s)?
> 
> Or I could just go away and leave it! Whilst I was away, it just decided
> to start working again. Mind you, I'd left it before for an hour and
> nothing happened. Weird.

Three possibilities:

* A server went offline:  If you have multiple servers configured, one 
went unreachable for a period, then came back.  Note that when you check 
headers (um, overviews...), pan creates a task for each server that a 
group appears on.  So if a server carrying 17 subscribed groups goes 
unresponsive, you'll get 17 stalled tasks, even if you have pan set to /
post/ to a different server for those groups.  You can get the same if 
you have say five such groups and try three times, plus try downloading 
two messages that appear on only that server (3*5+2=17).

You'll get similar behavior if a single "server" is in reality a many-
server backend, perhaps categorized, one server (or server group) for 
multi-part binaries, one for single-part-binaries, one for text groups, 
and one of the server-side servers it's mapping to goes down.

Or, if your connection hiccups and the server is left with a bunch of 
stale connections that are still counting against your allowed connection 
total, it may not allow further connections until the stale ones 
timeout.  With the common highwinds commercial server products, I believe 
there's one default timeout set to 15 minutes and another to three 
hours.  (And, unfortunately, I've seen it get connections stuck more or 
less permanently, that you have to contact the server admin and have them 
manually kill, as well.)  If you happened to trigger that three-hour 
timeout...

* Massive multi-million header (generally binary) group(s).  These can 
cause pan quite some pain as it doesn't scale as linearly as it might in 
this regard.  Things are **FAR** better than they used to be, but if it 
has to thread multiple millions of headers, as might happen when you 
first add a new heavy-use binary group or if you haven't visited/
refreshed a group for a time, it can take awhile.

Tho this probably was NOT your problem, as AFAIK, pan's entire GUI can 
appear to freeze in this case.

* Interfering local applications.  Some time ago people were having 
problems with pan going unresponsive for long periods when they were 
running gnome, but NOT when they ran kde, or something else.  That was 
kind of strange as pan is considered a gnome app, with gnome-hosted bug-
tracking and main public repository, etc.  So if anything, gnome SHOULD 
be the one with LEAST problems.  But as it turned out, there was some 
gnome accessibility daemon that Ubuntu had decided to enable by default, 
that... somehow... conflicted with pan, so pan could make essentially no 
progress sorting and threading headers after it fetched them.

Again, this probably doesn't apply to your case since AFAIK it made pan's 
entire GUI unresponsive, but that one was a humdinger to trace/debug 
since it only occurred with gnome and only if this daemon happened to be 
active.  First we had no clue, then someone quite by accident noticed 
that pan worked fine in kde but not in gnome and for a few weeks/months 
we were telling folks not to run pan in gnome if they were affected, 
while I had people comparing library versions and all sorts of exotic 
stuff.  Then I think it was Walt that finally made the connection with 
the accessibility daemon, after which it was easy enough to piece 
together the rest, that Ubuntu was now enabling it by default.

The thing to realize about that one is that while that accessibility 
daemon is the only known trigger so far, if it could do it, something 
else running locally could probably do it as well.  Altho, I think part 
of the problem there was that the daemon was running at a higher 
priority, under the assumption that people using it would be needing it 
to interface with their computer at all, and it and pan were apparently 
contending for some internal resource (presumably a kernelspace lock of 
some sort), such that it was essentially locking up pan, and very 
possibly the accessibility daemon as well.  But we didn't have anyone 
reporting that actually needed the daemon, so once Walt nailed it, it was 
easy enough to tell people that pan and it were simply incompatible and 
that if they wanted to run pan they had to turn the accessibility daemon 
off, which people happily did since they didn't need it anyway.

...

That means the offline server thing's the only real possibility I know 
of, here.  If it doesn't apply, then...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman