[Pan-users] Re: Pan keeps "forgetting" server

[Duncan]

Travis <address@hidden> posted
address@hidden, excerpted below, on  Wed, 23
Jul 2008 17:39:03 -0700:

> I never have a problem using sort by date with Pan (0.132).  I do it all
> the time.

Same here.  I know you're on MS, but I'm on (Gentoo/~amd64) Linux, 
running on reiserfs if it matters.

OTOH, I have 8 gigs memory, 2 by dual-core Opteron 290 (2.8 GHz) giving 
me four cores to run on, and most of the system including pan's working 
dir on four-spindle kernel/mdp RAID-6, so if it's taking too much time on 
this machine, something's definitely wrong!

I also keep pan in my active session, so it starts with X and KDE, 
because I have posts of some text groups saved for two years (multi-
gigabyte cache, set by hand in the config file), now, and pan takes a bit 
to reload all them, if the cache is cold anyway.  But other than just 
after a reboot (every few weeks, because I do run every other -rc kernel 
or so), I very seldom have a cold cache, and when I've just booted and 
entered X, there's other stuff I can be doing while it continues loading 
pan anyway, so it's not a problem.  Other than when X isn't running at 
all, I restart pan as soon as I've quit it, thus keeping it and posts in 
cache.  That way it starts nearly instantly.

Talking about restarting pan...  pan doesn't save state that often if you 
stay in a single group.  It'll save group state every time you change 
groups, but I'm not sure if it saves global state then or not.  I've thus 
gotten in the habit of switching groups every once in awhile if I'm going 
thru multiple-hundred-posts, so pan will save the state and I won't lose 
it all if it/X/kernel crashes for some reason.  It doesn't happen very 
often most of the time, but it was a few years ago when the xorg 
composite extension was newer and MUCH less stable, and that's when I 
(re)developed the habit.

I'd suggest doing something similar, only restarting pan, immediately 
after making any config change including setting up your server(s), etc.  
That's the only way to be sure the change in state is properly written.  
That way, a crash should /not/ take the server config with it.  Only if 
the entire system crashes, leaving a screwed filesystem that an fsck 
later corrects, lost&found-ing a file or whatever, should there then be 
an issue.

Oh... one more possibility.  0.132 (and previous) had an nzb related 
buffer overflow issue that was causing pan to crash in some instances, 
particularly if its tasks.nzb file was messed up.  This is/was a 
potential security issue as well.  A patch was posted and Charles has it 
in SVN for 0.133 now, but 0.133 hasn't been released yet.  If you are 
running a distribution version, ensure they've updated for that security 
vuln.  If you're compiling from SVN, as mentioned, it's already there as 
well.  If you're compiling from versioned source tarball, consider 
upgrading to svn or manually apply the patch as linked from bug 535413, 
here: http://bugzilla.gnome.org/show_bug.cgi?id=535413

It could be that you (OP) ran into that somewhere along the line, 
triggering a crash that corrupted something else.  Ensuring that you are 
running a patched version should in any case eliminate the nzb related 
sort of future crash, in addition to the related security vuln.

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