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

[Duncan]

Maurice posted on Sat, 22 Jun 2013 11:42:15 +0000 as excerpted:

> On Sat, 22 Jun 2013 05:24:26 +0000, Duncan wrote:
> 
>>  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,
> 
> 
> So I scooted back to Mageia-3 to do that.

Here's the usual Duncan detail post I promised. =:^)

> (N.B. In the previous session I had changed the Startup options to
> 'Start with an empty session')

Given the below, I don't think that was it anyway, altho there's still a 
missing piece to the puzzle that (like a real lost jigsaw puzzle piece) 
may never be found...

> First I tried starting Pan from a terminal session, which showed an
> extra warning:
> 
> ---------------------------------------------------------
> $ pan Gtk-Message: Failed to load module "canberra-gtk-module"

N.B. That one was discussed earlier and turned out to be a red herring, 
normal/harmless.  I guess it's simply posted again for completeness/
context, which is why this note as well, in case someone ends up googling 
this at some point.

> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
> news.pan.NZB was not provided by any .service files

FWIW, I get either this same notice or something very similar, here, so 
this too appears to be a red herring.  But it appears to have triggered 
your investigation that finally fixed it for you, and no arguing with 
that. =:^)

> ---------------------------------------------------------
> 
> I don't understand the reference to "news.pan.NZB', although there is in
> .pan2 a file 'tasks/nzb'

tasks.nzb , I think you mean.  At least that's what shows up here.  not a 
tasks subdir with a file named nzb ...

> containing:
> 
> ----------------------------------------------
> <?xml version="1.0" encoding="utf-8" ?>
> <!DOCTYPE nzb PUBLIC "-//newzBin//DTD NZB 1.0//EN"
> "http://www.newzbin.com/DTD/nzb/nzb-1.0.dtd";>
> <nzb xmlns="http://www.newzbin.com/DTD/2003/nzb";>
> </nzb>
> -----------------------------------------------
> 
> I tried deleting it, but it gets automatically recreated...
> Why is it there?

The *.nzb file format is a(n AFAIK informal) standard XML-based file 
format that has become *VERY* popular as a method for listing the 
individual split-message-posts that must be downloaded to complete a 
(normally binary-attachment) series.  Originally conceived by the 
newzbin.com usenet index folks, where it was developed as a compact 
automated-machine-parse-friendly single file description of the posts 
that must be downloaded to complete a series that appeared as a search 
result, it's now well supported by all sorts of news-related software and 
search sites.

Wikipedia link: http://en.wikipedia.org/wiki/Nzb

When Charles first did the pan2 rewrite (nzb is new enough it wasn't on 
the radar for pan 0.1x and previous), he tried to reuse common standards 
as much as possible, as well as having new-pan be nzb-file compatible.  
Once the code was written to have pan support nzb-files, it was thus only 
a small step from that to having pan's own saved-task-list file be an nzb 
file.

That's what this file is.  If pan has no incomplete download tasks queued 
when it quits, this file should be just the format-skeleton you posted 
above.  If there ARE incomplete downloads (whether actually running or 
not, say because pan is offline or there's no net connection) when you 
quit pan, it should store the posts it had queued to download in this 
file.

Do note, however, that the nzb format only saves message-IDs -- messages 
that would be in the process of download.  It doesn't have any provision 
for things like "check these groups for new headers", so those sorts of 
tasks will I believe be forgotten.  But that tends to be more practical 
anyway, as if the network's down for instance, and people have hit the 
get new headers button a bunch of times before giving up, it's probably 
best to simply forget that, especially since it's easy enough to start a 
new fetch headers job when you restart pan.

> HOWEVER, after the initial warnings Pan DID START, and continues to do
> so!

=:^)
 
> Now, the only change in my system settings since the failure was to set
> startup to 'start with an empty session'.
>    Also, I had been noticing (since the problem started) that during
> logout/Shutdown,I was seeing a brief flash of what looked like Pan's
> opening display.

What I believe now to have been happening is that the tasks.nzb file was 
corrupted due to a bad shutdown or the like.  This has been known to 
happen before, with a delete of the file fixing the problem, and I 
actually thought about the possibility, but rejected it, because...

You said that copying pan's data dir (which would have included the 
corrupt tasks.nzb) to a different user (along with changing all the file 
permissions accordingly) worked just fine.  In theory, if the tasks.nzb 
file was corrupt, that shouldn't have fixed the problem, since you'd have 
been dealing with the same corrupt tasks.nzb file.

So I rejected that possibility and didn't bring it up.  Seems like I 
should have anyway, as that seems to have been the problem after all, and 
deleting the file cleared it.

Which explains why pan might have flashed into existence briefly on 
restart, before hanging or whatever when it went to check where it left 
off and encountered the corrupt task.nzb file.

But that STILL leaves the missing piece of the jigsaw puzzle -- why/how 
could it have worked when you tried copying over the full data dir 
(including what we're supposing now to have been the corrupt task.nzb 
file) to a different user, reset file perms, etc, and tried it as that 
user?  That shouldn't have worked either, if it was a corrupt task.nzb.

One possibility is that you missed the perms on that file, so pan 
couldn't read the file and came up with an empty list, which would have 
worked.

Which is what I'll guess must have happened, even tho we may never know 
for sure.  Because it's the best explanation we have given the evidence 
at hand.  OK, so we didn't find the puzzle piece, but we cut another 
piece out of cardboard and drew a sort of outline of what the piece 
should look like...

Anyway, wiser now, next time I won't be so quick to discard the corrupt 
tasks.nzb theory, no matter WHAT the user said worked when he tried it as 
a different user! =:^)

> Could it be that Heinrich's suggestion (Pan already running) was on the
> mark, and that Pan wasn't starting because its session was still open at
> Logout, but for some reason was not being re-displayed at Login?  (And
> then setting 'start with empty session' had cleared that open session?)

It's possible that's part of it.  But I think the corrupt tasks.nzb thing 
was the real problem -- the reason pan was NOT redisplaying at login, if 
it was part of the saved session.

> Whatever, Pan 0.139 on Mageia-3 is back in business, but I shall play
> with it a bit more before permanently moving over from Mageia-2.

... And now you know what to try first should something similar happen 
again.  Always good to find out that sort of thing early on in the 
process, while you still have your old procedure/app/whatever available 
as a backup. =:^)

> Many thanks for your help, Duncan! Much appreciated...

And thanks to you, I and others reading now have it reinforced, if pan 
quits working, TRY DELETING THE ****** TASKS.NZB FILE! =:^)


@ Heinrich:

How easy would it be to catch a corrupt tasks.nzb and popup a warning 
about it, asking people if they would like it automatically cleared?  
(I'd suggest not clearing it without a prompt, as some folks might want 
to try to salvage it manually, and clearing without a warning doesn't 
give them that option.)

It's worth noting that a defect such as this is a very possible security 
exploit as well, if it extends to nzb file handling in general, which it 
probably does.  Because not every nzb file someone tries is going to be 
from a trusted source...

Additionally, how difficult would it be to do the create-a-new-temporary- 
tasks.nzb.tmp-file-then-rename-over-the-old-one, dance, that on good *ix 
filesystems is treated as an atomic rename operation so in the event of a 
crash either the old or new version exists, and the file shouldn't end up 
corrupted?

As I said above, I remember this happening at least once previously that 
was posted, which means it has probably happened to many other people who 
didn't post about it, too.

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