mintupdate: Not responding

[jakoblm]

LM 21.1 Beta Cinnamon running in a Virtual Machine:

Update manager crashed with the message "Update manager is not responding". The whole thing happened once while refreshing the package list and once after a successful update. Once even the system had to be shut down and restarted. By the way, the message would need to be translated into German, see other Issue: https://github.com/linuxmint/mint21.1-beta/issues/33

[jakoblm]

Also, the status message at the bottom left is not fully readable in German. I don't see any related message among the logs. If you need more info, I'll submit it.

[mtwebster]

Hi, can you run the update manage from a terminal:

killall mintUpdate
/usr/lib/linuxmint/mintUpdate/mintUpdate.py show

Then try to reproduce the issue, maybe it will provide some clues

Thanks

[jakoblm]

I have done that. Here is the output of the second terminal command:

/usr/lib/linuxmint/mintUpdate/mintUpdate.py show
/usr/lib/linuxmint/mintUpdate/mintUpdate.py:1326: DeprecationWarning: Gdk.threads_init is deprecated
  Gdk.threads_init()
/usr/lib/linuxmint/mintUpdate/mintUpdate.py:1698: DeprecationWarning: Gdk.threads_enter is deprecated
  Gdk.threads_enter()
/usr/lib/linuxmint/mintUpdate/mintUpdate.py:766: DeprecationWarning: Gdk.threads_leave is deprecated
  Gdk.threads_leave()
Installer: Generating new pkgcache
Installer: flatpak - updating appstream data for remote 'flathub'...
Installer: Processing Flatpaks for cache took 4836.149 ms
Flatpak: generating updates

(mintUpdate.py:1859): As-WARNING **: 15:42:15.410: re.rizin.cutter.plugin.rz-ghidra was of type addon but had no extends
Installer: Calculating Flatpak updates.
fetch task ready
Flatpak: done generating updates

Here is another screenshot, where you can see again that the status message at the bottom left is not fully readable. A little later, the same error message as on the first screenshot appeared again.

[pasch256]

the same here, only in english... btw, is in virtualbox 7 if that help.

[pasch256]

[becker44a]

I've experienced an issue that appears the same or similar to jakoblm's issue. Here are the details:

I’ve just loaded the 21.1 Cinnamon beta into a Virtualbox VM. All went well until I tried to run the Update Manager. UM started, but then hung – required a Force Quit to close it. Host unit environment: Mint 20.3 Cinnamon 64-bit, Virtualbox 6.1.38, VM: 1 vcpu, 3G RAM. After rebooting the VM, I was able to run updates. The status icon in the right panel reported the VM was up to date, but the automatic restart of UM hung again. System Monitor reported the CPU pegged at 100%. The CPU dropped back to normal levels after another Force Quit to close UM. After rebooting the VM, it appears to operate normally.

Next steps in load were to be installing some packages via Software Manager: vim, mc, gparted, gtkhash, etc. Ran into similar problems as w/ Update Manager – tool stops responding, CPU at 100%. Went to re-check Software Sources – selections were different than those I had previously selected. Re-do selections, re-try Software Manager. Got vim installed, vim-tiny removed, next search was mc, found Mc, but hung trying to bring up the install window. Left it alone for several hours – no change. Again needed a Force Quit to end it.

I switched to installing all the additional packages I needed using command-line: apt-get, apt-cache search, as needed. Every install attempted was successful – no hesitations, never pegged the cpu, all was normal. This seems to point to some issue in the Software Manager and Update Manager GUI interfaces.

For any additional tests or info, just ask. Thanks

[okaestne]

@mtwebster I think, that there might be user-local packages that might interfere with mintupdate. Had problems with this myself some time ago. Therefore I would propose a workaround like this: https://github.com/linuxmint/cinnamon/blob/b92a48873a8e5be8309418037cbadbbe85ce6cf3/files/usr/share/cinnamon/cinnamon-settings/bin/util.py#L6

[mtwebster]

There shouldn't be any though, if they're testing the iso - it doesn't sound like anyone might have done that here.

@jakoblm @pasch256 @becker44a: When the update manager froze, did you have any flatpaks installed and were selected for updating when the freezes occurred? Or were these just normal system updates?

[becker44a]

No flatpaks were installed - everything was a normal system update. None of the followup installs that worked without problems were flatpaks either. So far, I have found normal system packages for everything I want to use, and I don't want to load up Gigabytes of support for a few items I can normally do without.

[jakoblm]

There are no flatpaks installed and no other third-party sources in use. These were normal system updates.

[pasch256]

same here, no flatpaks installed, is a clean install.... normal update.

[mtwebster]

I can reproduce this - thanks all

[mtwebster]

Well, now I'm not certain - it's not something that happens every time.

It's possible the issue has already been fixed here, but it's not in the version on the beta: https://github.com/linuxmint/cinnamon/commit/a53596d7d5a56009d0560c6100e455778a956579

Without that, the cinnamon updater thinks it needs to download all thumbnails for all cinnamon spices every time it refreshes (instead of only once, then smaller updates after that). It downloads many of them simultaneously to save time. I wonder if the spices server doesn't like this (especially with lots of people doing this, whenever mintupdate refreshes in the background).

I'm not 100% certain here - are all of you using Cinnamon?

[pasch256]

in my case, yes i use cinnamon, but only in VM, and btw, in the issue #54 (yes i know is other report) i see some problem with the flatpaks cache... and that is another programan (software manager) that need thubmbnails, and some time freez, so i thinks maybe like you said, all the problems is server side.

[becker44a]

Yes, Cinnamon here, both Host and VM.

[jakoblm]

Yes, I also use Cinnamon, installed in a VM and as a live system.

[carlosmintfan]

@clefebvre Please not that mintUpdate also refreshes the flatpak cache when self.root_mode isn't true, is that needed? https://github.com/linuxmint/mintupdate/blob/master/usr/lib/linuxmint/mintUpdate/mintUpdate.py#L815

[clefebvre]

@clefebvre Please not that mintUpdate also refreshes the flatpak cache when self.root_mode isn't true, is that needed? https://github.com/linuxmint/mintupdate/blob/master/usr/lib/linuxmint/mintUpdate/mintUpdate.py#L815

I'd like to say no... it sounds wrong. I'll need to dig in deeper to make sure though.

[clefebvre]

If I remember right.. back in the days when mintupdate only dealt with APT, root_mode distinguished two types of checks:

• when True it involved refreshing the APT cache and thus properly checking for new updates online.
• when False it didn't have admin rights to refresh the cache, thus only picked up updates if the cache had been updated some other way

I think the update frequency set in the prefs relates to full updates, i.e. with root_mode being True.

Take this with a pinch of salt though. I really need to review the code to make sure this ^ is true.

[clefebvre]

From a user point of view, we don't need root permissions to check for flatpak and certainly not for spices. That said, if we set the preferences to dictate the refresh frequency, there's no need to perform these checks more often than the setting.

[carlosmintfan]

But mintUpdate can always refresh the APT cache, at least try to, if package management isn't locked by some other process. There's a sudoers exception for that. You can run mint-refresh-cache without having to enter your password. So root_mode means that we want a full internet update. If root_mode is False, then the refresh may be have "put to run" because there were changes detected to the APT cache, or because you opened the settings, or just because you started mintUpdate, maybe for something else also... But why did you comment the if line for flatpaks out?

[mtwebster]

We can probably restore that condition... it appears to be something I needed to revisit.

It was originally to make sure our appstream info (flatpak names, versions, summaries, etc...) were up-to-date for displaying updates. But we end doing that anyhow when we're actually getting the updates (_flatpak._initialize_appstream_thread()). It's about a 6mb file.

It's still worth running the full refresh in root mode I think. It will help keep it from happening when the Software Manager starts.

[clefebvre]

Yeah there's a sudoers permission at play. Don't mind the name of the variable. Historically, whether it was tied to admin perms or not, what it represents is whether or not the APT cache is refreshed from online.

[mtwebster]

Not going to close this yet, but I'll link some commits that should greatly reduce overhead when checking updates.

https://github.com/linuxmint/mintcommon/commit/d845884248214d05b7f93c344868ec386ee82436 https://github.com/linuxmint/mintupdate/commit/eef74ad7b5206e17b3559ef92cab86c1f5825d70 https://github.com/linuxmint/cinnamon/commit/108b77756b64620241f842622231a3412f6eeb28

[clefebvre]

included in:

• mint-common 2.2.4
• mintinstall 8.2.3
• mintupdate 5.9.2
• cinnamon 5.6.5

All live in Vera now.

[pasch256]

no luck... freez in the same thing... but in one time, when update appear, do the process and end successful, at least with last update.

[jakoblm]

Just now the update manager crashed again with the same error message. Previously, all updates were applied via the terminal and the system was restarted. Are you sure that the bug has been fixed?

[anaximeno]

I opened this issue https://github.com/linuxmint/mintupdate/issues/777 on mintupdate, and I believe it is somewhat related to this bug. I also created a MR with a proposal of solution in the mintupdate repo.

[clefebvre]

Fixed in mintupdate 5.9.4