[Pan-users] Re: "Redo" button in Tasks??

[Duncan]

Beartooth <address@hidden> posted
address@hidden, excerpted below, on  Thu, 20 Nov 2008
20:45:45 +0000:

> What is it supposed to do? Pan has taken to hanging interminably in
> unpredictable ways, either on one machine but not another, or one group
> but not another. I'm writing to my ISP, but I'm also trying to coax it
> to behave. I *guess* that it's supposed to re-start a queued task; but
> afaict, it does nothing at all. That can't be right ....

The redo button is indeed supposed to restart tasks, that you've stopped 
but not deleted, for instance.

The hanging is because pan is, for the most part, single-threaded (tho 
some specific parts are multithreaded), so if it gets stuck waiting for a 
reply from the server (the usual cause), the GUI gets stuck as well... 
until the timeout at least.

Restarting queued tasks when there are connectivity issues doesn't work 
so well, as you have observed.  It's designed for when you stop the task 
for other reasons (say you have VoIP and a call comes in, but you were 
using all your bandwidth for news so the call was choppy... stop some 
news tasks and free some bandwidth so the call will work better) and want 
to restart it/them.

Due to the way TCP/IP works, if the connection stalls, it may be better 
to kill pan if necessary, and reopen it.  The kernel will clean up the 
stalled connections, and you'll get fresh connections on the reopen.  Of 
course, if the connectivity is bad enough, the new ones will stall 
too...  

Meanwhile, what happens to pan's state when it gets killed depends on how 
much state it had that wasn't yet saved.  Note that if you are still 
running the security vulnerable 0.132 (or earlier) without the patch, 
this might leave the tasks.nzb file in a state that will cause pan to 
crash as it tries to open -- not good.  In that case you'll need to 
remove the tasks.nzb file by hand, losing the tasks that were in it.  
Consider upgrading to a patched 0.132 or 0.133 which has the vuln fixed.  
Of course, some distributions (umm Ubuntu..., Fedora was where the bug 
was originally filed but I'm not sure it's fixed either) still seem to be 
shipping the vulnerable version, months after it was fixed.  This has 
been quite frustrating for me watching them do nothing for months.

The other state that may get lost is the read message tracking for the 
group you are in.  When I'm working thru a group with many unread 
messages, I've taken to switching away from it (to a different group) and 
back every so often, forcing pan to save its state.  That way, I only 
lose the tracking on whatever messages I'd read since I switched away and 
back, not the possibly thousand messages or more I might have marked read 
without switching, otherwise.  This should only happen if pan crashes or 
is killed due to hung connections or whatever.  If it is closed normally, 
it saves its state on its own, as it does when switching groups.

-- 
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