Beartooth <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
