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

Xperia 10 III double sim (XQBT52), SfOs 4.5 0.19

as defaultuser, systemctl status mce returns immediatly so no process pending.

For me, it is happening for defaultuser just as well.

Maybe it depends on the actual output if it returns to shell or not. So please instead test it by displaying some large file that won’t fit on the screen in one go and will result in paging. For example please type as defaultuser:

more /etc/protocols

When it is waiting after showing the first page of output, please close the terminal window and check if the process remains active and quickly rises its CPU utilization.

I’ve just checked it on my 10 III, and the 4.5 OS’ more (that I renamed to more_old) process stays active and eats CPU, whereas the 4.4 OS more that I replaced it with quits instantly without any issues.

Sounds weird :thinking:. Could you provide also the more pager version for the clarity, e.g. more --version. I can personally reproduce this with more from util-linux 2.38.1.

1 Like

Yeah, that’s the buggy version.
Whereas the build from OS 4.4.0.68 which works perfectly fine is 2.33.

@nephros was right, it is definitely a regression, so I am going to update my bug report in the first post and change “Regression” to YES.

2 Likes

I now have been able to reproduce a pending more process as well, but only as root user (as phklrz mentioned).

1 Like

but only as root user

So maybe the bug is in devel-su and related infrastructure.

IIRC, normally processes should get killed when their parent PID exits - maybe the group and permission switching of devel-su somehow prevents this from happening.

Can everybody who can reproduce check the parent PID of offending more and other processes? And if it’s not PID 1, all the parent processes in the tree?

Also: anyone of you using su, sudo or pkexec instead of devel-su to gain root?

I have it as defaultuser just as well (there is absolutely no difference in my case, same issue for both normal user and root). Same for @Moppa5 and clearly also @tuplasuhveli. So it definitely isn’t root only. Besides, replacing the more binary with version 2.33 from 4.4 OS fixes the issue (again, for both defaultuser and root) so I see no connection with devel-su

Following are screenshots showing the very same issue while more is run as defaultuser, not root:

2 Likes

Aha! Found it I think:

These deal specifically with more, not other tools.

1 Like

more -e

doesn’t seem to make any difference. Same issue persists.

Also, I’ve just noticed that when more gets stuck in background after closing terminal and starts eating crazy amounts of CPU time, sometimes (but not always) a process called booster [generic] pops up and utilizes the very same CPU %. When I kill the offending more process, CPU usage of the booster [generic] process instantly goes down to 0%. So there must be some connection between them.

Actually, more -e does make some difference, but it doesn’t fix the issue. The difference that it makes is that on EOF (end of file) it automatically quits and returns to shell (rather than displaying (END) and waiting). So it solves the problem only in the specific case that the end of output is reached. But if we close the Terminal before we reach the end of multipage output (i.e. when more is showing some earlier page, without yet reaching the end), same problem happens, i.e. the process stays active in background and eats 100% of one CPU core.

@nephros, if you would like to test it yourself, this is the rpm package containing the buggy more. You might simply extract it from there and have some play with it…

https://releases.jolla.com/releases/4.5.0.19/jolla/aarch64/oss/aarch64/util-linux-2.38.1+git1-1.8.3.jolla.aarch64.rpm

1 Like

I encountered a similar problem a few times using wget. I used wget to download a test file to measure speed of an internet connection(over wifi). Closed the terminal, went outside, and a few minutes later my monthly mobile data volume was gone.

Added to internal tracker

2 Likes