Yast causing temp PC lockups, 100% CPU theads, screen locks up, mouse doesn't move

I’m using TW on an AMD Ryzen 7 MSI Bravo laptop with 16 cores and 40GB RAM and nvme system drive.

For the past few weeks after I boot up and log in a core CPU thread will run at max and will sometimes lockup my system for a minute or 2. “Lockup” means the mouse pointer doesn’t move and the screen is unresponsive. The 100% threads (active CPU core) will shift every 10 to 20 seconds. I’ve run some simple tests and when I close Yast the threads will go back to “normal” i.e. all cores idling at 0% to 5%. Sometimes it will take 5 to 30 seconds for Yast to close after I hit the close button.

Why is Yast causing this 100% max thread behavior? What logs do you need to see? How can I fix this?

I’m a Linux noob and have very very little knowledge of using the terminal.

Why is Yast running immediately after login? That doesn’t happen here. Have you done something on your desktop to auto-start it?

Note that you failed to even mention what desktop environment you are using.

1 Like

I startup Yast so I can turn on the Snapshot app. Yast was in my Autostart list but I removed it. But I still need to turn on Yast every day to manage my snapshots.

My desktop is Gnome / Wayland / Dash2Panel.

Anyway to fix this issue of Yast overloading my system?

I’m not a regular Gnome user, though I do occasionally experiment with it.

I would guess that the overload is due using Yast as a startup rather than manually starting it later. Maybe there’s a timing conflict between Yast and something else that runs during Gnome startup.

But I’m just guessing.

2 Likes

If you wanted to look into the issue, the wiki indicates the following:
Y2DEBUG=1 strace -eopen -ostrace.log /usr/lib/YaST2/bin/y2base lan qt.

you of course dont want to run with strace constantly but maybe instead as a test start a wrapper script and let it run for few seconds clocking. Like, a script like this?:

#!/usr/bin/env bash
Y2DEBUG=1 strace -eopen -ostrace.log /usr/lib/YaST2/bin/y2base lan

Alternatively, I suppose you could do a similar thing and instead of debug, just hard code some sleep 30 before yast is run.

Hopefully someone can correct me if a better way to debug. I both never use Gnome and am unfamiliar with Yast. Just looking at:

https://en.opensuse.org/openSUSE:YaST_debugging

1 Like

@invalid_user_name Maybe packagekit and friends… or tracker… I use neither.

1 Like

Disabling packagekit and discover6notifier in KDE provides significant RAM savings. With my 4GB of RAM these packages make the difference… I followed @hui advice. And I really have to thank him

UPDATE: I turned off autostart for Yast but the problem is still there. I removed all my autostart items and the problem is still there.

I did a few simple tests and looks like the problem is not tied to or confined to Yast. When the problem is happening the “gnome-system-monitor” process is using the highest amount of CPU, about 0.8% total (and about 60 MB of RAM). Seems small but my system keeps locking up. Frustrating.

I have 40 GB of RAM but only about 4-7 GB of RAM is being used when the problem is happening.

One core (out of 16 total) will be at 100% for 10-20 seconds, then switches to another core. This will continue for about 10 - 15 minutes (with periodic lockups) before it stops and my system goes back to normal.

Is there a way to identify the exact process PID that is causing a series of single cores to peg at 100%? Can the logs show which process is controlling which core(s) for a time period? And show what % of core is being used?

Maybe a command to log when a core gets used 100% capacity and which process is doing it?

1 Like

just throw off your packagekit. that was a mistake to keep it

1 Like

On which facts is this comment based?

1 Like

what reply you refer for ?

1 Like

Your comment…

1 Like

i experienced freeze mouse and abnormal activity caused by the running packagekit. after i remove them, my problems gone out.

1 Like

I’m using Gnome and based on some quick research, it looks like removing packagekit will mess up Gnome, so I better keep it. But I’m a noob. Comments from experts most appreciated.

1 Like

@invalid_user_name just disable the service(s) and mask it then…

1 Like

Based on my noob research disabling packagekit will cause Gnome to malfunction and that could mean I can’t use my computer to get my work done.

Are you saying that disabling packagekit will not effect Gnome functioning?

Also, how can I make sure that it’s actually packagekit that is causing one of my cores to peg at 100%? (and thus cause the big slowdowns I’m experiencing?)

@invalid_user_name I run GNOME, first things I do are remove plymouth, disable packagekit and tracker stuff (which may be you issue…). My boot time is quick, happy to control package management, don’t need stuff indexed…

  1. So you’re saying disabling packagekit does not cause you any Gnome problems? That sounds good.

  2. If I disable packagekit, can I still successfully run “sudo zypper dup”?

  3. What is “tracker stuff” and how do I disable it?

Please remember I’m a Linux noob and don’t know any Linux under-the-hood stuff.

@invalid_user_name

  1. Nope
  2. Yes
  3. As my user (–user) disable and mask;
systemctl --user list-unit-files | grep tracker

tracker-extract-3.service                                             masked    disabled
tracker-miner-fs-3.service                                            masked    disabled
tracker-miner-fs-control-3.service                                    masked    disabled
tracker-writeback-3.service                                           masked    disabled
tracker-xdg-portal-3.service                                          masked    disabled

So, systemctl --user disable <some service> and then swap disable to mask and run again.

1 Like