High CPU usage/runaway process by MXPI after closing.

[CharlesV]

Hmm... in your ~/.config folder there is an MX-Linux folder with the mx-packageinstaller.conf file - Possible rename that to z_mx-packageinstaller.con ( or move it to a backup location some place ) and then retest.

[turfymiler]

I renamed mx-packageinstaller.conf as suggested and re-tested. Unfortunately it made no difference. I opened Package Installer, clicked About, then closed the application. After a couple of minutes it was using 25% CPU again despite being closed.

I see reference to Flatpaks in the .conf file. I don't use them and think I turned off something relating to Flatpaks somewhere in MX in the past. Can't recall where now. Mentioning in case it might have any bearing on this issue.

[retroD0d0]

Specifically this happens when you open MXPI, perform no task and then close it. I have tested across 5 23.6 installations on 5 separate systems and with the live .iso. Same thing. Including Fluxbox, XFCE and KDE and even the Minimal spin. My workaround is to make sure I get MXPI to 'do something' before I close it, such as updating the package lists.

[Adrian]

Specifically this happens when you open MXPI, perform no task and then close it. I have tested across 5 23.6 installations on 5 separate systems and with the live .iso. Same thing. Including Fluxbox, XFCE and KDE and even the Minimal spin. My workaround is to make sure I get MXPI to 'do something' before I close it, such as updating the package lists.

Not sure, I don't see that happening, one clarification, MXPI is not meant to be opened and closed immediately, it loads stuff in its cache, it loads the Debian package info, it loads the flatpak stuff, so when you click on the next tab it would be responsive and you don't have to wait for everything to populate. But that should not take more than a few seconds. Do you see the problem if you open MXPI, leave it on for let's say 30 seconds and then close it? How do you test this?

[turfymiler]

Tested again just now. I opened MXPI, selected Enabled Repo tab, clicked Refresh List, waited for one minute, then closed MXPI. As before the fans came on after a couple of minutes and Task Manager showed MXPI process using 25% CPU.

It does not seem to matter what I do in MXPI, every time I close it the MXPI process in Task Manager its CPU use goes up to 25%. I timed it this last time and the MXPI process which remained in Task Manager at 0% after I closed it went up to 25% after 1 minute 20 seconds.

[Eadwine Rose]

Start the test again, this time start it from the terminal. Paste the output if any.

[turfymiler]

I did the same test as in my previous post but this time started MXPI from Terminal. Same result, CPU use for MXPI went up to 25% after a minute or so.

After I close MXPI the line for its process remains in Task Manager showing 0% CPU. Shouldn't the MXPI line disappear after it's closed?

Terminal output:

Code: Select all

$ mx-packageinstaller
mx-packageinstaller version: 25.09
+++ void MainWindow::setup() +++
apt-get update --print-uris | grep -m1 -qE '/mx/testrepo/dists/bookworm/test/'
+++ void MainWindow::loadPmFiles() +++
+++ void MainWindow::refreshPopularApps() +++
+++ QHash<QString, PackageInfo> MainWindow::listInstalled() +++
LANG=C dpkg-query -W -f='${db:Status-Abbrev} ${Package} ${Version} ${binary:Synopsis}\n'
+++ void MainWindow::displayPopularApps() const +++
apt-config shell APTOPT APT::Install-Recommends/b
"APTOPT='false'"
+++ void MainWindow::displayPackages() +++
+++ void MainWindow::tabWidget_currentChanged(int) +++
+++ void MainWindow::setCurrentTree() +++
+++ bool MainWindow::buildPackageLists(bool) +++
+++ void MainWindow::clearUi() +++
+++ bool MainWindow::downloadPackageList(bool) +++
+++ bool MainWindow::readPackageList(bool) +++
+++ void MainWindow::displayPackages() +++
+++ QHash<QString, VersionNumber> MainWindow::listInstalledVersions() +++
+++ void MainWindow::filterChanged(const QString&) +++
+++ void MainWindow::updateInterface() const +++
LANG=C apt-get --dry-run autoremove | grep -Po '^Remv \K[^ ]+'
+++ bool MainWindow::buildPackageLists(bool) +++
+++ void MainWindow::clearUi() +++
+++ bool MainWindow::downloadPackageList(bool) +++
+++ bool MainWindow::updateApt() +++
pid=$(fuser /var/lib/dpkg/lock 2>/dev/null); [[ -n "$pid" ]] && ps --no-headers -o comm -p $pid
"Get:1 http://security.debian.org/debian-security bookworm-security InRelease [48.0 kB]"
"Hit:2 http://deb.debian.org/debian bookworm-updates InRelease"
"Hit:3 http://deb.debian.org/debian bookworm InRelease"
"Hit:4 https://brave-browser-apt-release.s3.brave.com stable InRelease"
"Hit:5 https://mirrors.ukfast.co.uk/sites/MX_antiX_packages/mx/repo bookworm InRelease"
"Ign:6 https://repo.vivaldi.com/stable/deb stable InRelease"
"Hit:7 https://repo.vivaldi.com/stable/deb stable Release"
"Hit:8 https://repo.librewolf.net librewolf InRelease"
"Get:9 http://security.debian.org/debian-security bookworm-security/main i386 Packages [271 kB]"
"Get:10 http://security.debian.org/debian-security bookworm-security/main amd64 Packages [278 kB]"
"Get:11 https://zotero.retorque.re/file/apt-package-archive ./ InRelease [2,153 B]"
"Fetched 598 kB in 1s (660 kB/s)\nReading package lists..."
""
sources updated OK
+++ bool MainWindow::readPackageList(bool) +++
+++ void MainWindow::displayPackages() +++
+++ QHash<QString, VersionNumber> MainWindow::listInstalledVersions() +++
+++ void MainWindow::updateInterface() const +++
LANG=C apt-get --dry-run autoremove | grep -Po '^Remv \K[^ ]+'
+++ void MainWindow::pushCancel_clicked() +++
+++ void MainWindow::cleanup() +++

[Adrian]

Does it get stuck in terminal at "cleanup()" stage or returns the prompt?

I really cannot replicate what you are seeing, do you see that if you run a clean ISO (release with up-to-date mx-packageinstaller)?

Do you reliable get the elevation prompt when you install/remove something? Do you have pkexec installed on your system?

[turfymiler]

Yes, it does get stuck in the Terminal. It doesn't return the prompt. I do get the prompt back when I kill the process in Task Manager.

I downloaded a clean ISO for 23.6 Xfce. When I boot from USB stick I don't get the problem. When I close MXPI the process disappears from Task Manager.

Sorry, I don't know what you mean by " elevation prompt when you install/remove something".

Yes, pkexec is installed on my system.

Re latest version of MXPI, I am running the latest version available to me in MXPI, the Enabled Repo tab says both Repo and Installed versions are 25.09. I update my system whenever MX Updater prompts me too.

I noticed that when I ran MXPI from the ISO on USB stick it had both Repo and Installed versions as 25.09.01. I guess that may be why you think I don't have latest version on my system. I'd install 25.09.01 but I can't see it in MXPI, MX Test Repo only has 25.09 too.

[retroD0d0]

Not sure, I don't see that happening, one clarification, MXPI is not meant to be opened and closed immediately, it loads stuff in its cache, it loads the Debian package info, it loads the flatpak stuff, so when you click on the next tab it would be responsive and you don't have to wait for everything to populate. But that should not take more than a few seconds. Do you see the problem if you open MXPI, leave it on for let's say 30 seconds and then close it? How do you test this?

Hi, I think you are dead right, if I wait a long enough time (around 40 seconds on tested system), it shuts down correctly! If I close MXPI too quickly, then the runaway process starts about 5-10 seconds after closing. Whatever process it is, it consumes a single core per instance, so 50% on my dual core system for example. I started from terminal as Eadwine suggested and I get a similar output to turfymiler, it hangs on "cleanup" if I close too quickly, the process exiting only when I manually sigterm.

Code: Select all

$ mx-packageinstaller
mx-packageinstaller version: 25.09
+++ void MainWindow::setup() +++
apt-get update --print-uris | grep -m1 -qE '/mx/testrepo/dists/bookworm/test/'
+++ void MainWindow::loadPmFiles() +++
+++ void MainWindow::refreshPopularApps() +++
+++ QHash<QString, PackageInfo> MainWindow::listInstalled() +++
LANG=C dpkg-query -W -f='${db:Status-Abbrev} ${Package} ${Version} ${binary:Synopsis}\n'
+++ void MainWindow::displayPopularApps() const +++
apt-config shell APTOPT APT::Install-Recommends/b
"APTOPT='false'"
+++ void MainWindow::displayPackages() +++
+++ void MainWindow::pushCancel_clicked() +++
+++ void MainWindow::cleanup() +++

It wasn't like this before however, I'm pretty sure this anomaly was introduced in an update this year, but I can't be more precise sadly.

edit: After @turfymiler test with a clean .iso, I just did a sanity check with the latest clean, freshly downloaded XFCE August Snapshot, running Live w/persistence, with solely the MXPI package updated to latest 25.9.1 The issue is still there for me!

The problem is that this issue is quite insidious by nature. It will quietly eat CPU cycles. Restarting MXPI and this time performing a successful shutdown doesn't terminate the original runaway instance.