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 mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users