[Pan-users] Re: Pan hanging on exit

[Duncan]

Joe Zeff posted on Sun, 23 Aug 2009 23:52:52 -0700 as excerpted:

> I'm a Fedora user, thankyouverymuch, but I did play around with that
> recently.  (Bad eyesight.)  The screen magnifyier did too much and was
> too unresponsive so I stopped, but it was still checked.

Ahha!

> The issue with
> forgetting which articles I'v read has cleared up, but I'm still waiting
> for pan to finish exiting.  (Ah, there; it's done now.)  The file
> keeping the data for the group is up to about 1.8 Meg by now; could that
> be part of the problem?  I know there's something in pan about deleting
> the articles, but I haven't tried it yet.

You're talking about the file(s) in the groups subdir?

FWIW, while I'm running a bit better machine than many (older, but dual 
dual-core Opteron 290, so four cores, 2.8 GHz, 8 gigs RAM, 4-SATA-spindle 
Linux kernel/md RAID-6 main system), in my text instance (I make use of 
the PAN_HOME environmental var to point pan at different directories, 
thus different settings, cache, everything, for text, binaries, and 
test), I have the cache set to several gigs, expiration set to not expire 
at all, and track about two dozen groups.  I have messages going back 
more than two years on my ISP's server, and of course use gmane.org to 
participate in various lists including this one, with messages (well, 
headers, I've not downloaded all the messages that far back) there going 
back as far as the group/list on gmane does, to 2000 in at least one case.

For the text instance du says the cache dir is 325 MB (for perspective, 
pan's default max cache size is 10 MB, before it starts deleting old 
messages as soon as it can to get it back in range, and I run a dedicated 
partition of 12 gigs for my binary instance cache, naturally I've had it 
filled) and the groups dir is 26 MB.  ls -lSh says the largest file in 
the groups dir is gmane.comp.kde.linux, at 6.3 MB.  Assuming that's what 
you were referencing, your 1.8 meg file is thus small compared to what 
I've accumulated here.

For settings, I have pan set NOT to download new headers at open or when 
I enter a group, and NOT to mark-all-read when I leave a group or exit.

Given all the above, from a cold cache pan /does/ take some time, several 
minutes, to open -- nearly 100% i/o-wait time, BTW -- the disks aren't 
particularly fast even tho it's effectively two-way-data striped (plus 
two parity stripes).  But I start pan with KDE so it's already going when 
I want to use it, so the startup time isn't /that/ big a deal the way I'm 
handling it now, even from cold-cache.  However, once the data's in-cache 
(memory), if I close pan and open it again, it restarts almost 
immediately.  Again, it's the slow disk i/o that's the startup bottleneck.

However, once it's open, it runs quite well, and it closes pretty close 
to instantly.

Thus, there's something wrong with your setup if it's taking that much 
time to close.  You said the gnome accessibility agent was still running, 
right?  You unchecked it, which presumably means it won't start again, 
but did you verify (running ps or top or whatever GUI task manager) that 
it was stopped?

Also, once it's stopped, if pan was running, it might still take awhile 
that first time to close -- I don't know enough about what the 
interaction is there to know for sure.  But, starting pan and then 
quitting, after the first time once the accessibility agent is stopped, 
should now be faster.

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