Re: pan stops working/responding

On 9/9/23 12:03 AM, Duncan wrote:
> dchmelik-Re5JQEeQqe8AvxtiuMwx3w posted on Fri, 8 Sep 2023 00:31:29 -0700
> as excerpted:
>
>> On 9/7/23 2:26 AM, Duncan wrote:
>>> dchmelik-Re5JQEeQqe8AvxtiuMwx3w posted on Thu, 7 Sep 2023 00:20:07
>>> -0700 as excerpted:
>>>
>>>> If I select a high-activity group I haven't read before (such as
>>>> gmane.linux.kernel which I guess is the mailing list and has hundreds
>>>> thousands posts) pan soon stops working/responding.  I can no longer
>>>> select any other group, nor any menu item, and if I cover or minimize
>>>> pan and return later, it no longer even redraws its screen.  Today
>>>> this has gone one for about six hours, which just to show one screen
>>>> of posts, it shouldn't take this long!  I don't know why it'd have to
>>>> prepare to show all posts from years ago because I probably won't look
>>>> that far back.  Pan even stops responding like this if I mark that
>>>> I've read all articles in the high-activity group and come back later,
>>>> perhaps just to see the top page of articles.
>>> Please verify the following preference is UNCHECKED:
>>>
>>> Preferences > Behavior > Groups > Get new headers when entering group
>>>
>>> (I keep Get new headers in subscribed groups on startup unchecked as
>>> well,
>>> for similar reasons, but if you're careful not to subscribe to groups
>>> that are too high volume that should be less of an issue, because
>>> unlike when you first enter a group, presumably pan has a memory of
>>> where you were in all your subscribed groups.)
>> I set both those preferences and tried to read gmane.linux.kernel
>> again... same happened.  This time I waited several hours, came back
>> several times, waited overnight and checked a few more times, and
>> finally waited 30 hours before I reboot so pan got killed.  I think pan
>> getting killed in the past messed up how it saved some files and was
>> causing the crashing I was having for years.
>>
>>> Then, when grabbing your first headers, us the get headers ... dialog
>>> instead of getting new/all headers, and get the last N-days-worth or N-
>>> hundred headers, thus restricting that initial header download.
> For purposes of comparison, I just tried that group (gmane.linux.kernel)
> here.  I don't think I had visited it before as it popped up the get-
> headers dialog on its own when I entered the group.
>
> The get-headers dialog defaulted to 60 days worth of headers.  I said OK
> and let it fetch.  It now says it has 16,205 unread (I didn't click on any
> so they all remained unread).  FWIW 8k/mo messages isn't actually as bad as
> I had suspected it might be based on the comparisons I've seen to reading
> LTML being like trying to drink from the end of an active firehose...
> certainly compared to some of the busiest binary video groups, tho there
> 1000-to-1 or more multipliers due to the binaries aren't uncommon so it's
> different.
>
> Took a few seconds I guess.  FWIW, ~ decade-old 6-thread amd fx6100, 16 gig
> RAM, long upgraded to SSDs tho, with my pan text-mode instance on a
> dedicated 5-gig capacity filesystem  with 3.6 gig free (btrfs raid1 mode
> data/metadata both, on a pair of 5-gig partitions, one on each of a pair of
> ssds), inet connectivity throttled by an old 100 Mbit ethernet WAN router.
>
> So agreed, something's definitely screwed up with your pan.
>
> Next thing to try...
>
> I'm assuming you've already done an fsck (or equivalent filesystem check on
> MS) and it's clean, and you've run smartctl -AH or the like to check disk/
> ssd health, also clean.
I think my OS does this on every boot and it was clean after I got up... 
I think I'd get GUI notifications if the SSD or HDD was damaged.

> In your pan dir (on *ix, ~/.pan2 unless you've set $PAN_HOME (as I have),
> IIRC):
>
> First try a quick fix... if it works.  Maybe the tasks.nzb file is
> corrupt.  Assuming you don't have any uncompleted downloads or the like
> that you'll miss, with pan closed, just delete that file.  Pan will
> recreate a fresh one when it restarts.
>
> Next, check groups/gmane.linux.kernel.  If it exists it should be a text
> file; FWIW ~6.1 MB after the above load, here.  You should be able to just
> delete it if desired since you haven't gotten the group to load anyway, but
> you may want to load it in a text editor to see if there's any obvious
> corruption (switches to binary part way through or something) first.
>
> We'll check and edit the gmane.linux.kernel lines in the newsgroups.xov and
> newsrc files too.  For these files you likely want to make backups before
> editing since if the files get screwed up it can mess up pan's tracking for
> all the other groups too.
>
> Open your newsgroups.xov file in a text editor.  Does it have a line for
> gmane.linux.kernel?  FWIW, here's mine (again, after the above header load,
> there's a comment line at the top of the file with the format)
>
> gmane.linux.kernel 16205 16205 1:4908585
>
> Try just deleting the line (and saving, with pan closed of course) if it
> exists.
>
> And finally, the newsrc file(s), of which you'll have one per server, with
> the newsrc:server mapping found in servers.xml.  This tracks read messages
> based on server message-sequence numbers.  Note that due to cross-posting
> pan may have some messages listed as already read based on them being read
> in other groups even if you've never (successfully) opened the listed
> group.
>
> FWIW, here's the entry I have for that group in my gmane newsrc (single
> line in the file, it'll wrap at the single space after the exclamation,
> here):
>
> gmane.linux.kernel!
> 0-7380,50432,50440,50445,50503,159981,198273,217961,222263-222265,228815,260045,321972,322043,322163,624724,624752,625133,625286,625787,625820,625
>
> Again, try just deleting the line (and saving) if it exists.
I did all above except deleting it from newsrc, because there weren't 
numbers after it anyway (not even wrapped to another line) and I didn't 
want to have to delete & re-add it... seemed it was just a normal entry 
that wasn't affecting the problem.  After this, I got the last week's 
headers, which are 2.3MB, and was able to take a look.  The groups file 
was 1.8GB and apparently hadn't even finished (I don't know how large it 
would've been if I got it from the beginning of Gmane which I don't have 
much reason to right now).

> With any luck that should unscrew whatever's screwed up for that group, and
> you can then successfully do what I did as a quick check for LKML, above.
Thanks! :)


_______________________________________________
Pan-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/pan-users