"Extremely busy" was created again. PM was minimized, after a "Finite-time Freeze" (see another thread) and not rebooted, but with 10+ hours idle with no internet connection . Htop showed 1-4% CPU, sometimes 12%.

I clicked on a desktop "Help" item that turned out to be a html file, with PM the default viewer.
However, no PM window was maximized or created. Instead, Htop showed 2 new PID's labeled "palemoon -file:///usr..." using 18-25% CPU, with other PM PID's using more CPU, and total CPU constant at 100%.

Using the kill command on the parent "palemoon -file:///usr..." (the one launched to display a local file), I was surprised that they were killed (removed from list in Htop) but the other PM PID's were not (CPU 35-47%) and total CPU remained at 100%. Switching to Htop tree-view and killing the lowest PM child with no CPU shown, all PM's were gone and CPU usage was back to 4%.

Before, the "Extremely Busy" state seemed to begin while idling; here, it was created at a specific time.

What Htop view would be most useful? The regular one which seems to show newly-running threads at the top, or the tree-view which has all the Palemoons together? If the tree-view with PM is on screen, the top info of Htop is probably off-screen.

Also, upon rebooting this am, I opened one PM from the Internet menu, minimized, then opened that help file mentioned previously; I thought I remembered new files opening as tabs.

However, it opened a new window and left the old one minimized. But looking at Htop, no PID was labeled with the command line including file:///... like I saw before, all just said "palemoon".

And there were 30+ of them, although the first PM window just had a single "restore session" tab and I hadn't actually made any internet requests yet.

Now, because PM crashes so much, that "restore session" had a lot of history in it, many sessions of restore. Could they be creating PID's?

Is there a certain stage when a process with the PM command line for opening a file is created, but then it is terminated with the actual file contents handled by other PID's? Or does this mean the process was the desktop's, and PM actually hadn't loaded yet?

Clicked on that Help file. CPU total went to 100% (couldn't see which PID responsible) for about 2 seconds, then a PM window appeared, total CPU down to 96%, then a tab "connecting" appeared in that PM window, then the local file appeared with the tab changing its title, and total CPU 2.79%.

Well, here is a screenshot for an "extremely busy" PM (I was wrong about the header of Htop, the other threads scroll under it).

This was taken about a hour after an unresponsive tab in one of two PM windows was closed- several times on the X, then, minutes later, the "unresponsive script" box (clicked stop), and finally went away & both PM windows working OK.

When the screen shot was clicked, the Htop PID was at the top of the window, by the time Screeny actually worked, more threads had opened above them.

I was then able to recover normal operation. Although Htop showed total CPU solid 100%, the PM parent was shown as 42-69%. Since the PM's were minimized, I right-clicked for "Close" on the one that had had the bad site. Then it maximized, and I clicked the X. Then the "confirm close" appeared (because there were 5 tabs) and I confirmed. Then the PM parent showed 60-73%, and contents of the "confirm" box when blank, the box remaining. Then the contents came back, PM showing 25% then 49%, then 80%, and box changed to "unresponsive script". Clicked "stop", PM showed 70%, then window gone, and Htop total down to 73%, then 60%. Then PM parent showed 60% for a second, then total Htop CPU 12%.

Other PM window now works, but in the course of typing this, sugglishness has increased, sometimes 2 sec for screen updates, with frequent total CPU peaks in Htop of 40%, 98%, etc.

...in an xterm/whatever? Expand the terminal window to full screen. This will give the parameters (if any) passed to Pale Moon. Before posting the screen shot, check that there's no embarressing URLs that you'd rather people not know you're visiting.

Without any options, it gives just one (parent) PID, identified under the COMMAND column as just "palemoon", with PPID shown as the PID of JWM (the desktop manager), and %VSZ 81%, %CPU 12%, and not changing as fast as in Htop. In Htop, that parent ID is shown as launched by "jwm /bin/sh -c palemoon". Using arrow keys, one can see farther down to the kernel PID's, but nothing mentioning PM.

Not clear to me how it updates if rxvt is a terminal window. Could one save a snap-shot output to a file by using STDOUT (>) redirection?

New Tobin Paradigm wrote:For clarification, htop can see threads and puts them in a tree LIKE child processes but they aren't processes. Pale Moon IS a multi-threaded application.

That explains a lot.
I don't use htop so I didn't know. Thanks for the explanation.

That said, there's still the question about wether it's expected for jwm to have another jwm as a child (unless it's a thread!), about why everything is run as root, and if this can be part of the problem.
Also, OP should provide the info from about:troubleshooting.

Some more info. Apparently this issue has something to do with desktop painting.
With one PM window with 1 or 2 tabs on screen and idle (no IP connection or mouse action) for 10+ hrs, the "extremely busy" (Htop CPU solid 100%) condition occurred again.

When that PM window was maximized again, CPU again 100% (PM 20-50% CPU), and content of PM window (below tabs) was empty. Other windows could be maximized and were sluggish (1-2 sec to redraw), but PM window took several minutes to redraw.

About Htop: if command lines shown in green are threads not processes, why do they have unique PID's?

This system is Xenial 7.5 Puppy Linux on a CD; everything is root by design.

That Codeahoy page was interesting but doesn't explain much on internal details, like how those % are calculated.

Those screen shots were of the Palemoon threads and didn't show the other running stuff above. But even using "sort-by CPU" option, to get threads using CPU together on a screen, they don't add up to what is shown in the header by about half. And with "sort by resident memory", the %'s do not add up correctly either.

Maybe certain kernel threads or overheads are not measured.

That screen shot was the first time I saw a "D" for status of anything.

After being idle for longer today, when I got back to it, again 100% CPU. PM had been left minimized with no IP, with only one Wikipedia page plus an unused "restore session". What I found on screen was an "unresponsive script" box. Is that correct that it would be on screen even if PM was minimized? Although I could maximize/minimize windows. was not able to get a screen shot because I couldn't get JWM to start by right-click, and forgot the other ways.

I've never had a Wikipedia page, with no multimedia etc, have an "unresponsive script"; does that mean that the "restore session" had a script, or is the real error triggering that box by mistake?

I did manage to close that box after waiting several minutes for it to respond, but even though nothing from PM was on screen, the CPU usage did not go down as in a previous case, still being 19-41%. I did notice Htop was using 40% too, and I think I saw "pmcputemp" ("poor man's CPU temperature" supplied with Puppy) using 8% CPU and 234M memory, resident I think. This is surprising since this program usually uses 0% CPU and 27K virtual memory, 18K resident. The previous screenshots did not show pmcputemp because I had concentrated on PM. Will check closer next time. Because the threads jump up & down in list, I could have been mistaken.

This computer's disk activity light is positioned so you don't see it in peripheral vision, and I don't usually look for it. But in normal operation, I never see anything listed as status "D" in Htop. During the occurrences described here, only once did I see things with status D- and then it was lots of stuff, like the Xorg lib and Frisbee as well as PM.

Htop shows you have a tiny swap file of 128 MB, and all of that is in use.

Your problems are very likely due to running out of RAM and swap space, which is no surprise when you have that many tabs open on a 1 GB system--even more likely if they are "heavy" pages such as news sites, etc.

moonbob69 wrote:Since this system is on CD-ROM, I don't see a setting for increasing the swap size but will keep looking.

Do you have a "maintenance mode" where you can resize disk partitions, inc;uding the swap partition? You'll need to unmount partitions before resizing them. What is the output of the command df when run from the commandline (xterm/roxterm/whatever)?