Re: [Pan-users] Pan 0.139 refuses to start!

[Duncan]

Maurice Batey posted on Fri, 21 Jun 2013 16:59:52 +0100 as excerpted:

> On Fri, 21 Jun 2013 08:40:08 +0000, Duncan wrote:
> 
>>  I /believe/ canberra is the gtk sound event module.
> 
>    I suspect the 'canberra-gt*" warning is a red herring; I was probably
> getting that (but not seeing it) when starting Pan from the system icon.
> 
> The reason I say that is because I have tried Pan on a 'junk' user on
> the system. (Copied my .pan2 directory over, and chown'ed the
> permissions.)
>    Pan did start with it, even though the 'canberra' warning stilll
> appeared first.

Kde apps are notorious for alarming looking but apparently harmless STDERR 
"noise" like that.  I guess devs simply don't expect users to be running 
stuff from a terminal window where they'll see it, but it sure hampers 
reasonable troubleshooting! =:^(


>     So, why is Pan  being difficult for me but not for 'junk'?

Good question.  If it's working with the full pan data dir transferred 
over, then we know it shouldn't be a problem with pan's config or data, 
AND we know it still works in general on the system.

That means it "has" to be something else in your user config.  Maybe a 
bad theme or something?

> I've done an 'strace -o strace.txt pan', the output from which can be
> seen here:
> 
>    https://dl.dropboxusercontent.com/u/10969499/strace.txt
>    
> If anyone has time to look and can see a possible explanation I would be
> a very happy bunny...

Well, I looked, but I'm not technical enough to get much out of the full 
dump, at least not without some sort of guidance as to what I should be 
looking for.

Here's a couple suggestions on where to go next.

1) Bisect.  Since we can be /almost/ certain based on the above that it's 
something in your user config, contrasted with the config of the junk 
user, and that it's NOT the pan config which would be the normal first 
place to look since you have that transferred already, one approach would 
be to bisect your existing user config down to the troublesome bit.  This 
is somewhat tedious, but it doesn't require a lot of technical smarts, 
just enough to copy stuff around without screwing up, and a lot of 
patience.  I'll outline the general procedure first, then some tweaks 
that can help the process go faster by shortening the number of test 
cycles needed.

First, ensure you have a good backup of your entire user config, that you 
can copy stuff back and forth from without problem.  One way to do this 
would be to (as root) rename your /home/user dir to say /home/user.bak, 
making it your backup, then create a new /home/user dir to repopulate.  
Also, ensure you have sufficient free space so you won't be running out 
of space if you double your user data.

Now, copy roughly half your user data, including the pan data dir 
(~/.pan2/ by default) back to the new user dir, and try booting into it 
and running pan.

If pan runs, you know the problem is in the other half.  If pan does NOT 
run, you know it's in the half you copied over.  If you wish, you can 
confirm that by deleting the half you copied over, and trying the other 
half (remembering to include the pan data dir itself, since you already 
tested it above).

When you know which half is bad, you can copy over the good half (if it 
was the bad half you had tested) and leave it in place, since you know 
it's good.  Then copy over (or delete) roughly half of the bad half, thus 
a quarter of the total, and repeat.

Repeat as necessary with the bad half, bad quarter, bad eighth, etc, 
until you get a single bad first-level dir.  Then dive into that dir and 
continue with subdirs, then with files, until you find an individual bad 
file.  At that point you should have a good idea where the problem is 
just by the file name, and can either try deleting it and reconfiguring, 
or dive into the file (assuming it's a text config not a binary) and 
continue the process by file section and then individual line.

Of course at any point you can decide that the remaining data isn't 
enough to bother with and can simply delete it and reconfigure from 
there.  Personally, I'm the type that likes to know /exactly/ where the 
problem is, and once I get to the point that I'm comfortable with 
reconfiguring from there, I'm close enough to knowing the /exact/ problem 
that I like to continue down to the individual bad config file line, if 
possible, but some may prefer to simply reconfigure what's left at an 
earlier point, and skip the last few testing cycles.

Meanwhile, of course the above brute force method can be optimized quite 
a bit depending on what you know of the problem.  In fact, given that 
it's a pan problem, generically, chances are in general pretty good that 
the problem's in the pan config, so an immediate optimization is to only 
test that, which you already did, and found that it works in a different 
user environment, so OK, we gotta step back a bit and do a larger bisect.

However, it's still almost certain that things such as your mail config 
and data, media files, etc, won't have a lot to do with pan, so you can 
try copying all of the stuff you suspect can't have anything to do with 
it in one go and test that, or alternatively, exclude all that and copy 
over only the stuff you suspect COULD have something to do with it, say 
your desktop environment config.  The latter will likely be easier since 
all those media files would presumably be a LOT of data.

(FWIW, I have a separate media file partition, with symlinks to it from 
the appropriate locations in my user config, in part for this very 
reason.  Thus I can leave it in place for such testing, and test by 
simply mount/umounting it, or by copying/deleting the symlinks to it, as 
appropriate.  Since media files are so huge and so unlikely to be related 
to the problem, that means I copy FAR less data around and the process 
takes FAR less time.  It also means I don't have to worry so much about 
having enough space for a full additional copy of everything, since the 
data I'm actually duplicating for my test is far smaller.)

The mention of symlinks in that parenthetical brings up another possible 
optimization.  At the directory level anyway, you can often simply 
symlink, rather than copying over the whole dir.  This may or may not 
work at the individual file level, depending on how the system actually 
uses that file.  (A popular way to help ensure that either the old config 
or the new config remains, even if there's a crash while saving the new 
config, is to create the new config as a different file, then rename it 
over the original in an operation that good filesystems treat as atomic.  
However, that can screw up our symlink testing method, if a config file 
is automatically written out at app-close-time even if there were no 
changes.  So symlinking may not work at the file level, but it should be 
more reliable at the directory level.)

However, one caution about symlink shortcutting: sometimes one 
component's config will differ depending on the presence of another 
component, or the component will have config files in two different 
places.  If the two dependent parts of the config aren't treated 
together, as they likely won't be at some point in the bisect process, 
the part of the config that's symlinked may be rewritten to reflect the 
fact that the other part wasn't available.  So symlinking isn't always a 
good idea for configuration testing, tho it can work very well for media 
files, etc, which aren't rewritten and tend to be bulkier to copy around 
in any case.

The first few times you do a config bisect troubleshooting session, it'll 
take quite awhile, many cycles, because you'll be working mostly blind.  
By about the third time, however, you'll be getting a far better 
understanding of the layout of your desktop environment and what sorts of 
config files affect what, so will be able to make educated guesses as to 
the problem much more effectively, and will thus be able to optimize your 
bisection far more effectively, cutting down on the number of bisect 
cycles needed to actually find the problem.

As a bonus, you'll understand far more about your desktop environment and 
where and how it stores its config, due to simple familiarity with the 
files in question. =:^)

FWIW, I've been using this technique successfully on kde (and even back 
before the turn of the century on MS) for years, since long before I knew 
the proper name for it.  These days there's actually a bisect tool that's 
part of the popular git distributed source control management system, 
where users and even devs routinely bisect a problem down to an 
individual commit, which then they can report and have the dev 
responsible for that section of the project take a look and see what went 
wrong, already knowing what code change triggered the problem. =:^)

2) While that strace isn't very helpful to me on its own, if I had the 
corresponding strace of a successful run to compare it against, and 
possibly a diff between them (tho I could of course do that myself once I 
had both straces in hand), that would spotlite the differences, which 
COULD be quite helpful. =:^)

So try an strace of starting pan on the user where that works, just to 
the point at which pan is up and running successfully.  (Copy off the 
strace output file at that point, before quitting pan.)  Then post a link 
to it along with a repost of the link to the first one (so I don't have 
to go back and find it), and perhaps with that additional guidance as to 
where to focus by spotliting the differences between them, I can actually 
find something useful in the straces.

(A bonus would be if you could do that after setting up the bisect, so 
the user is actually the same such that the paths to user files won't be 
showing up as noise in the diff.)

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