"more" (and others, e.g. "top") keeps running in the background after closing Terminal and uses 100% of one CPU core

REPRODUCIBILITY: 100%
OS VERSION: 4.5.0.19
HARDWARE: 10 III
UI LANGUAGE: Polish, English
REGRESSION: YES

DESCRIPTION:

If you execute a command in the Terminal that uses more for its output (which doesn’t automatically end and return to shell) and you just close the Terminal window without first terminating the running command (e.g. using Ctrl-C) so that it ends and returns to shell, the more process keeps running invisibly in the background, uses 100% of one CPU core and eats a lot of battery.

(Similar thing applies to also other commands which don’t automatically return to shell, e.g. top, whose processes also stay running in the background, it’s just that their CPU usage is lower, see the “Additional information” section below).

A good example of a command using “more” for output is systemctl. So to reproduce this issue, just type e.g.

systemctl status mce

(which will display the status of the mce service and then wait at the (END) prompt without automatically exiting and returning to shell) and close the Terminal window. Now use some tool to check running processes (be it top or htop in Terminal, or some GUI tool like Crest) and notice how the more process keeps running in the background, using literally 100% of one CPU core and eating your battery like crazy, as can be seen on the following screenshots.

Htop output showing 100% usage of CPU 6 by the more process:

Top output showing 12.4% of CPU usage by more process (it shows usage of all cores, so it equals 100% usage of one of the eight cores as 12.4% ~ 100/8

Crest output:

PRECONDITIONS:

None

STEPS TO REPRODUCE:

  1. Open Terminal
  2. Execute a command using ‘more’ to display its output, e.g.: systemctl status mce
  3. Close the Terminal
  4. Use top, Crest, or whatever to see running processes, notice 100% usage of one core by ‘more’ process still running in the background, also notice battery level very quickly decreasing

EXPECTED RESULT:

Closing the Terminal should terminate the execution of more, as it is much too easy to forget to manually terminate it. If it stays running invisibly in the background, it uses 100% of one CPU core and eats battery like crazy.

ACTUAL RESULT:

After closing the Terminal, if not manually interrupted e.g. by Ctrl-C, the more process keeps running in the backround, uses 100% of one CPU core and crazy amounts of energy.

MODIFICATIONS:

None related.

ADDITIONAL INFORMATION:

This is 100% reproducible, i.e. it happens each single time if the output of ‘more’ is not manually terminated using e.g. Ctrl-C prior to closing the Terminal window. Be it a bug or not, something should be done about it because it is way too easy to leave the more process invisibly running in the backgroud this way, and it has really bad consequences as it eats battery like crazy.

Even worse, it is actually NOT limited to just more, but to many other commands, which also stay running in the background after closing the Terminal, of which a good example is e.g. top. It’s just that (so far) I haven’t seen such an enormous CPU usage by those other processes (e.g. top when left running uses only 0.5 - 1%) but they are also there and also unnecessarily eat power, take CPU time and memory.

4 Likes

Maybe a duplicate of [4.5.0.16] Closing terminal while viewing journalctl leaves "more" process consuming CPU?

Well, actually not a duplicate because the issue reported here is NOT limited to journalctl as reported there but it applies to every command utilizing more for output. Even worse, it is actually NOT limited to just more, but to many other commands, which also stay running in the background after closing the Terminal, of which a good example is e.g. top. The only difference is that those other processes (like e.g. top) don’t use 100% CPU like more (top uses some 0.5 - 1%) but they are also unnecessarily left running, eating energy and taking CPU time and memory.

I can not reproduce on 4.4 with gnu-bash as default shell. Might be a regression.

I’m quite convinced that I’ve had it already on 4.4, it’s just that it took me quite a while to report it. Or maybe I’m wrong and it was introduced only on 4.5…? Hmmmm. Anyway, recently it’s been really a major PITA, as despite being aware of it I keep forgetting and closing the Terminal without manually terminating it first, and then (e.g. in the morning) ending up with seriously drained battery.

Xperia XA2 on SFOS 4.5 here (32bit) and bash as default shell. I do have ‘less’ as the default pager (can’t recall how I configured that in the past), but I cannot reproduce it using ‘more’ or ‘top’. Everything gets cleaned up after closing the terminal and never had issues with remaining processes this way.
What shell are you using; bash, busybox-ash or some other shell?

Jolla’s default.

As for the XA2, indeed, strangely, by default it uses less instead of more so you won’t get this issue with commands like journalctl or systemctl, because their output is using less which is correctly terminated when the Terminal window gets closed.

HOWEVER, if on the XA2 you manually execute more to display some file and you close the Terminal window while it is running, you will get exactly the same issue on the XA2 (32-bit) as on the 10 III, i.e. the more process remains running and utilizes 100% of one CPU core. Identically as on the 10 III.

Simply type more [name_of_some_file_to_show] in the Terminal and just close its window while the file is being displayed.

The top command also stays running after closing the Terminal on the XA2U. And uses some CPU just like on the 10 III (not much, up to 1.5% or so, but still…). I can reproduce it with top every single time, so please re-check it.

To recap, the XA2 and 32-bit builds of SFOS are equally affected as the 10 III, it’s just that by default they use less instead of more, so to test it one needs to manually execute more with some file to be shown.

Top gets terminated every single time. The only thing I can think of is bash has some impact on this behavour, but setting /bin/ash as default shell and then start a terminal session also terminates top on close. No further clues at the moment.

Strange, as on my XA2U it stays running every single time…

And what do you get if you manually execute more to display some file? Just like top, it stays running each single time and eats 100% CPU.

Like I said in my first response, top and also more vanish after closing the terminal. I did test it with “more file.txt” active in the default Terminal and also in ToeTerm.

Maybe we need more input/responses from people with other devices/SFOS versions.

If I run more via ssh and I close the connection while it is running (showing some file), it gets correctly terminated on both the 10 III and XA2U. Same with top. If I run them in the phone’s Terminal application, both get stuck. So I don’t know what to think about it.

So… can someone else please try to reproduce it?

  1. Open Terminal
  2. Type systemctl status mce or (if the phone is 32-bit where less is used) e.g. more /etc/salifish-release
  3. Close the Terminal window
  4. Check using e.g. top or Crest or Lighthouse or whatever if more process keeps running and eating CPU time

Thank you.

I tried :slight_smile:

Here you have my results:

I don’t have this issue… Maybe because I still use SFOS 4.4 (?)…

1 Like

Yes, I can reproduce this with Xperia 10 II running the latest 4.5 release. I’ve been able to reproduce this similarly with any application utilizing more as you’ve described as well, having also personally reported this behaviour with the journalctl.

At least to me this seems to be a regression as I’ve used journalctl and thus “more” pager a lot and never encountered this for instance with 4.4 or earlier.

2 Likes

Apparently in OS 4.4 more behaves differently, because in your case, as can be seen on your first screenshot, after displaying the file more automatically quit and returned to shell. Whereas on SFOS 4.5, on both my 10 III and XA2 Ultra, after showing the very same file, more displays a white (END) line at the bottom but doesn’t quit (it takes e.g. pressing Ctrl-C to terminate it). If you don’t terminate it but instead close the Terminal window, it stays in the background and rises its CPU utilization to 100% of one core.

So it seems that OS 4.4 was not affected and the bug was introduced only in 4.5. Clearly, there’s a different (and buggy) version of more in it.

What does more --version show?

1 Like

Indeed, as @Shocker reported above, it looks that it is a regression and OS 4.4 wasn’t affected yet. On his screenshot one can see that in OS 4.4 after displaying the /etc/sailifsh-release file, instead of displaying that white (END) line and still running, more automatically quits and returns to shell. So there clearly was a different version of more in OS 4.4, free of this issue.

So maybe I’ll downgrade to more version from OS 4.4…

And that’s what I did - I replaced more with version from OS 4.4.0.68. And it fixed the problem.

If someone wants to do the same, the packages from OS 4.4.0.68 containing more are as follows:

For aarch64 (64-bit) devices:

https://releases.jolla.com/releases/4.4.0.68/jolla/aarch64/oss/aarch64/util-linux-2.33+git4-1.8.6.jolla.aarch64.rpm

For armv7hl (32-bit) devices:

https://releases.jolla.com/releases/4.4.0.68/jolla/armv7hl/oss/armv7hl/util-linux-2.33+git4-1.8.5.jolla.armv7hl.rpm

Rather than installing the rpm (which contains several other utils and it would replace them all), I suggest to extract more from it and manually replace it in /bin/ and then chmod +x it and chown it so that root is the owner. That’s all. Works like a charm.

P.S. Of course, this is just a workaround. The buggy more version in OS 4.5.x.x should be taken care of.

1 Like

Xperia 10 III and 4.5.0.19 here, I can reproduce this 100%. Sorry for taking so long to test this.

  1. I ran command more /etc/sailfish-release.
  2. Checked with crest the process more was consuming 0,0% CPU.
  3. I closed the terminal (fingerterm in this case).
  4. After a few minutes I checked again with crest: the process more is consuming more (:D) than 80% CPU.

Good thing you brought up this bug, @wetab73!

2 Likes

Happens only if you do it as root.
I guess that since fingerterm is launched by defaultuser it can’t terminate a process belonging to root.

1 Like

At least to me this is not limited to executing as root and I’m running on Xperia 10 II with latest 4.5 release. For instance, running the command systemctl status mce with defaultuser, as suggested by @wetab73, results to the exact issue.

If you’re experiencing this issue only as root, I’d suggest you also provide specs for device, Sailfish version etc.

1 Like