[Pan-users] Re: Pan 1.20 closed unexpectedly, then won't start since

[Duncan]

"Roger T. Imai" <address@hidden> posted
address@hidden, excerpted below, on  Sat, 28 Jul 2007
21:12:54 -0500:

> Recent Windows refugee on Ubuntu Feisty. Pan 1.2 ran fine for a few
> weeks, then yesterday unexpectedly closed without any warning in the
> middle of a batch retrieval, and I haven't been able to re-start Pan
> from the Applications menu since. Clicking on the launch icon gets no
> response, no error message.
> 
> I've tried:
> 1. Uninstalling & re-installing from Add/Remove 2. Re-installing over
> using Synaptic Package Manager
> 
> I found out that I could start Pan from the Root Terminal [snip]
>  
> Would appreciate any suggestions. If possible phrase your instructions
> for a former intermediate Windows user, rank Linux newbie (2 months.)

Welcome! May your time on Linux and with pan be enjoyable and useful. =8^)

Let's see if this is clear enough.  If not, don't hesitate to ask further.

pan 1.2?  pan 1.20?  It's possible this is a strange Ubuntu version, but 
pan doesn't have such versions as it ships.  I'm guessing (I don't run 
Ubuntu so can't say for sure) it's pan 0.120.  It may also be something 
way old like pan 0.14.2.  After you get this straightened out, you may 
wish to upgrade.  The newest version is 0.131, and there's an Ubuntu user 
that contributes packages, as can be found linked from the pan site, 
http://pan.rebelbase.com .  There have been a number of fixes since 
0.120, and it's possible it'll be more stable for you.  I'll let him step 
in and give you specific upgrade steps if necessary, however, because as 
I said I don't run Ubuntu, or indeed any Debian based distribution (FWIW, 
I run Gentoo/amd64), so I couldn't give you the specifics.  

Meanwhile, back to the problem at hand...  The problem would appear to be 
that the crash corrupted pan's database.  The following is a bit deeper 
than it has to be, but is intended to help you become the intermediate 
user on Linux you were on MSWormOS.  Again, ask if anything's not clear.

As with most programs intended to be run by the user (as opposed to the 
sysadmin) on Unix/Linux, pan can normally only write to the user's home 
dir and possibly other locations the user has write permissions for.  It 
can't write to the system area or to other users' home dirs.  Thus, an 
important troubleshooting technique on Linux, when something won't work 
for a particular user, is to try it for another user.  I've actually 
found it's sometimes useful to create a "testing" user just for that 
purpose.  Keep its profile clean/generic, so there's no cruft built up, 
and don't hesitate to blow its config away once in awhile so it /has/ to 
start with a clean profile.  If it works for that user, you /know/ it's a 
problem somewhere in your normal user's config.

Also note that it's generally /not/ a good idea to use root as the test 
user.  For one thing, if an app is screwed up bad enough, running it as 
root could kill the entire system, since root can overwrite anything, 
including system data and that of other users.  For another, because 
root /does/ have those extra permissions, running an app as root isn't 
testing whether an ordinary user can run it at all.  So, the idea is, 
create your test user and try it first.  If it works, you know it's a 
problem with your normal user's profile or data, since it works with one 
regular user but not another.  You may however occasionally run into 
permissions issues, where you suspect that a regular user simply doesn't 
have permission to do whatever it is you are testing.  In /that/ case, 
it /may/ be useful to try it as root, BUT BE VERY CAREFUL when you do so, 
keeping in mind that if something goes wrong, if you are running as root, 
it could REALLY go wrong, and screw up your entire system.  Also, be very 
careful about running anything that connects to the untrusted Internet as 
root.  Since you can't control what someone posts to the newsgroups you 
subscribe to, that includes pan.  If someone tries an exploit when you 
are running pan as your regular user, the max they can do is damage that 
user.  If someone does the same when you are running pan as root...  (For 
this reason, it's also worth keeping your really valuable stuff, bank 
records, etc, as a user other than your regular one.  That way, if 
someone /does/ get in and can access your regular user's files, they 
still can't get at your /really/ important info, since it's not 
accessible by your regular user.)

OK, hopefully that didn't scare you away. =8^)  If not, maybe you're one 
more step from newbie to intermediate user on Linux, too. =8^)

So now we know pan's data is corrupted.  How do we fix it?  Well, pan's 
data is stored by default in ~/.pan2.  (Older versions used ~/.pan.)  As 
you may or may not already know, on Unix like OSs including Linux, ~/ is 
a shortcut for your home dir.  It doesn't always work, but it often does, 
and its a useful convention when one doesn't know what particular user is 
being discussed or whether the standard /home/username convention is 
being followed on that particular system or not.  Also, a leading dot 
beginning a filename makes it "hidden" -- it won't show up in most 
regular directory listings and the like.  Thus, ~/.pan2/ refers to a 
hidden subdir of your homedir, called .pan2.  If you don't see it in your 
file manager of choice, either enable viewing of hidden files, or just cd 
into the dir by entering the path directly.

>From here, it's up to you.  If you haven't customized pan all that much, 
and don't have any particular reason to want to save the stuff you've 
downloaded that's still stored there, you can simply blow away the 
entire .pan2 dir and start over again.  OTOH, if you're like me and 
customize things enough that you cringe at losing more config than you 
absolutely have to to get things working again, it's likely we can save 
most or all the files there.

To try to salvage what's salvageable, while at the same time pinning down 
the problem to a particular file, use the old trial and error method.  
First, save off everything to a backup dir.  Then, try deleting various 
things, a subdir or a group of files at a time, trying to start pan with 
each try.  If it still fails, try a different subdir/filegroup (copying 
the files you deleted back from the backup); if pan works, you've 
probably found the culprit and can move on.  Once you pin down the subdir 
or file group, subdivide it further.  Once you get an individual file, 
you can stop there, or if appropriate, dive into that file and use the 
same technique lines at a time rather than files at a time.  The files 
are named intelligently so you can sort of figure out what's in them, and 
pan uses text based files, not unreadable binary junk, so diving into 
individual files either to see what they are or to delete specific lines 
for troubleshooting purposes, shouldn't be difficult.

It's possible you'll find that the problem is a particular post or 
overview line that pan chokes on.  If so, as suggested above, install the 
latest pan (0.131) and try again.  If it's still choking on it and you 
are comfortable doing so, consider filing a bug on it.  You may also wish 
to post the message-id, group, subject, author, and date, here, so others 
can confirm if it's a problem for them or not.

So anyway, you should be able to get pan up and running under your normal 
user again, even if you simply delete all its data and start over.  
However, if you have a bit of patience, it's likely you can trace the 
problem further, likely recovering all but that one file or even specific 
lines within the file.  Hope this has been useful. =8^)

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