[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] Pan 0.139 refuses to start! [SOLVED]
From: |
Duncan |
Subject: |
Re: [Pan-users] Pan 0.139 refuses to start! [SOLVED] |
Date: |
Mon, 24 Jun 2013 11:48:39 +0000 (UTC) |
User-agent: |
Pan/0.140 (Chocolate Salty Balls; GIT 459f52e /usr/src/portage/src/egit-src/pan2) |
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
- [Pan-users] Pan 0.139 refuses to start!, Maurice Batey, 2013/06/20
- Re: [Pan-users] Pan 0.139 refuses to start!, Duncan, 2013/06/21
- Re: [Pan-users] Pan 0.139 refuses to start!, Maurice Batey, 2013/06/21
- Re: [Pan-users] Pan 0.139 refuses to start!, Duncan, 2013/06/22
- Re: [Pan-users] Pan 0.139 refuses to start! [SOLVED], Maurice, 2013/06/22
- Re: [Pan-users] Pan 0.139 refuses to start! [SOLVED], Duncan, 2013/06/22
- Re: [Pan-users] Pan 0.139 refuses to start! [SOLVED], Heinrich Müller, 2013/06/23
- Re: [Pan-users] Pan 0.139 refuses to start! [SOLVED],
Duncan <=
- Re: [Pan-users] Pan 0.139 refuses to start! [SOLVED], Maurice, 2013/06/24
- Re: [Pan-users] Pan 0.139 refuses to start! [SOLVED], Duncan, 2013/06/24
- Re: [Pan-users] Pan 0.139 refuses to start! [SOLVED], Maurice, 2013/06/24
Re: [Pan-users] Pan 0.139 refuses to start!, Heinrich Müller, 2013/06/22