[Pan-users] Re: Messages not visible (again)

[Duncan]

Julien Michielsen
<address@hidden> posted
address@hidden, excerpted below, on  Mon, 29 Sep 2008
13:46:23 +0200:

> A few days ago I posted a message that pan did not show the messages it
> had collected from the server. I got a message from Duncan that the
> error probably was caused by an old ~/.pan directory. So - as he
> suggested - I created a new .pan2 directory, and everything went fine (I
> thought): I could read the newly posted messages, and I thought I could
> read messages and use Pan as it was intended. However, a few days later
> when I tried to collect new messages, they did not show up in the
> pan=panel. After starting up, it shows an upper line showing "File Edit
> Go Groups Articles Post Help" and some icons. There below a large panel
> which is subdivided in two sub-panels: the left one showing Subscribed
> groups and a line Other Groups. The right sub-panel did show messages in
> subscribed groups I had not read yet. But at present it is entirely
> empty. When I try to re-read a newsgroup I can see a number of lines is
> read, but nothing shows up with headers showing the titles and contents
> of the messages. Anyone a hint what to do to make the messages visible
> (again ;-) ) Thanks

The symptoms you describe are somewhat vague, and could be caused by one 
of several things.  Without more info it'd difficult to answer 
appropriately.  The below is sort of shooting in the dark, hoping I hit 
something that you recognize as possible in your circumstances and can 
work to check and correct if necessary.

Are you still using 0.132?  If you haven't upgraded to 0.133, have you 
checked to see if your distribution has patched that security vuln I 
mentioned in the other post?  (And BTW, which distribution or OS are you 
using?  If I knew that, I could possibly make some of the below a bit 
more specific.)  It should be listed in the changelog, or try searching 
your distribution's bug database and see if it is listed and fixed, 
there.  It had to do with the way pan handles *.nzb files, including 
pan's own tasks.nzb.  While the problem usually results in a crash, it's 
conceivable that it might simply fail to fetch further updates (or to 
clear existing tasks thus the problem) in some cases.  I'd call this one 
not so likely, but because there's a potential security issue involved 
and there's a known fix, I'm listing it first.

Perhaps the simplest fix might be if you set the display to filter 
messages incorrectly.  Under the view menu, header pane submenu, make 
sure all the "match only" entries (save perhaps for match only unread) 
are NOT checked.  One time I set pan to show only my own messages for 
some reason, and forgot about it.  Needless to say I was left wondering 
why nothing was showing up, until I chanced across the check, remembered 
what I had done, and undid it.  Similarly, at least for testing, make 
sure all the "match scores of..." entries are CHECKED.  If there's a bad 
score marking /everything/ ignored, you won't see it unless that's 
checked, after which it'll be EASY to see what's going wrong.

Did you perhaps crash pan, or shutdown with pan running and downloading, 
or even after simply checking messages for a group without switching to a 
different group when you were done?  Pan saves state for a group only 
when you change groups, so one thing I've learned to do here is to always 
switch to a different group when I'm done reading messages and the like, 
so it saves what I just did in the /last/ group.  Fail to do that and you 
will likely lose the state for that group, tho other groups should be 
fine.  Of course, if you crashed while pan was actively downloading or 
something, you could lose more.  Actually, that's what most often 
triggers the *.nzb bug I mentioned, but other files may be corrupted as 
well.

What filesystem do you have ~/.pan2 on?  ext3?  fat?  reiserfs (what I 
use)?  Something else?  How long has it been since you did a proper fsck 
on the filesystem?  Perhaps filesystem issues are causing things to go 
haywire.

Related to that, have you had any other strange issues with crashes or 
disappearing files?  Maybe it's hardware (failing disk?) related?

Under pan preferences (edit menu), on the behavior tab, what are the 
settings under Groups set to?  In particular, are the following set 
checked or not: get new headers on startup, and when entering group, and 
to mark group read when leaving group, and when getting new headers?  
Obviously, if you don't have pan set to grab new headers at startup or 
when entering a group, you won't get anything new until you tell it to do 
so. If you have the view set to hide read messages (as mentioned above), 
you read all the old ones (or had pan mark them read automatically 
according to your preferences), and you haven't fetched new ones (or 
there's no new ones to fetch yet), there won't be anything new to display 
until you fetch new headers. 

Talking about which... There are three "get headers" buttons.  Unless you 
use the middle one, "get headers in subscribed groups", pan won't do 
anything until you enter (or select) a group, because the first button 
works on the group you are in, and the third works on selected groups.

....

If the above doesn't turn up anything, maybe it's time to get out the 
diagnostics tools and see what pan's actually doing.  First, run pan from 
a terminal window.  Do your normal thing and see if pan spits out any 
unusual messages to the window it was run from.  Of course, close pan 
before closing the terminal window.

Another thing you can try is the trial and error problem bisection via 
filesystem approach.  Basically, you move your entire pan data dir 
(~/.pan2, unless your distribution changed it or you you have the 
PAN_HOME environmental variable set) elsewhere, say to ~/.pan2.test.  
Then restart pan and see if it looks right, which since it started 
without a config will be a brand new clean installation, no config yet.  
If that works, close pan, delete the stub dir it created, and copy some 
files, say everything but cache, back.  Now open pan again and see if it 
has your setting back, but without what would be expected to be missing 
based on the files you didn't copy back.  Work back and forth by trial 
and error, deleting files or copying more back, until you find the 
culprit config or data file.  If it's a config file, you can then dive 
into it, removing parts of it while keeping other parts, until you nail a 
specific section (if appropriate), then a specific setting in that 
section.  I've used this sort of troubleshooting technique to find and 
fix problems I didn't otherwise know enough about to fix, a number of 
times.  It requires a LOT of patience, some intelligent guessing in 
figuring out what parts of the config are most critical and what parts 
are least likely to be involved, a bit of luck, and often a LOT of time, 
but it's surprisingly effective.

One more possibility, but it gets rather more complex.  Assuming you're 
on some form of Linux (other OSs should have similar utilities), try 
(from the terminal window) strace -eopen pan (assuming you have strace 
installed, if not, you may have to install it).  That'll spit out quite a 
bit of output as pan opens various files to read from them.  Most of the 
early ones will be libraries, fonts, icons, and system config files. If 
you know how to use grep you can filter most of that out as we're not 
interested in it for what we're doing. You'll probably be amazed at how 
many pan opens or tries to open.  But then it'll start opening its data 
files, and this is where it gets interesting.  Verify that it is indeed 
using the ~/.pan2/ dir (perhaps your distro changed the defaults and it's 
using something else?), and note any file open errors it gets.  You can 
save the output by redirecting it to a file using > like so:

strace -eopen pan > ~/pan.filedump

If you have a web page or other location you can post files to and link 
them, you can then post the link here and we can take a look and see if 
anything looks strange to us.  (Of course, be sensitive to the fact that 
the filenames may include the newsgroups you subscribe to.  Some people 
wouldn't mind that being public info.  Others would mind as that can be 
rather personal info and may be embarrassing.  It's your choice of course 
whether you post it, and entirely understandable if you don't wish to.)

Other than that... unfortunately it could well be one of those things I 
could fix if I were there, looking at the actual machine where I can see 
things I'd miss remotely and try stuff without the latency of a mail 
exchange, but that's incredibly difficult to fix remotely.  If you 
mention the distribution/OS, filesystem, etc, perhaps someone else with 
more specific knowledge in that area can be of help.

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