steam-runtime-system-info high CPU usage, sometimes hangs

[yat-L]

Your system information

• Steam client version (build number or date): 1526683293
• Distribution (e.g. Ubuntu): Arch linux
• Opted into Steam client beta?: [Yes/No] No
• Have you checked for system updates?: [Yes/No] Yes

Please describe your issue in as much detail as possible:

System information High Cpu usage for steam client, one CPU stuck at 100%.

Steps for reproducing this issue:

1. launch steam
2. wait about 30 second to 1 min
3. check htop, there is always 1 CPU at 100%

htop screenshot:

Tried launching steam-native in terminal, here is the full output. I marked the line where the CPU start to have high usage, at the bottom.

The issue start when the line : Installing breakpad exception handler for appid(steam)/version(1526683293) appear after the steam client open.

[Marco-GG]

Detected the same problem since the last update. I'm in Ubuntu 16.04.

[Marco-GG]

Side note: if I kill all steamwebhelper process, the cpu usage gets normalized.

[srakitnican]

Happens on Fedora as well. 100% CPU usage from steam process around 15 seconds after Steam Client is started and lasts until the Steam Client is closed.

[shaolo1]

I never had this problem before, but ever since the civ6 launcher changes I'm having steam stick at 100% cpu if I leave it running...or if i leave computer idle too long.
Running Ubuntu 18.10

[shaolo1]

Is there any update on this? I can't leave a game for 5 minutes without coming back to find steam has lost its mind or is mining bitcoins or something nuts.

[shaolo1]

Today its worse. Steam goes to 100% while I'm actively playing a game..not in idle state. What is going on with this?

[espentrydal]

I have the same problem on Ubuntu 18.10. 100% on one core. Steam in tray won't quit, I have to kill the process. Then cpu usage normalizes.

[lordlymight]

I have the same problem on Mint 18.1. As with someone above, I found about 6 steamwebhelper processes, and CPU usage went back down after I ended them.

I think this is the first time I've had this issue; I've used Steam on this OS before recently without issues. Possibly there's been a recent update and this is the first time it's tried to download a game, but I don't know for sure.

Edit: Doesn't seem to be (just?) because of downloads; I slept and then unslept my computer and had the same problem (many steamwebhelper processes; killing them restored CPU usage.)

[jromang]

Same problem here, ubuntu 18.04

[EterniaLogic]

The only thing that I can think of is that there is a drawing thread for bigpicture or event thread for the tray icon that does not have a Thread.sleep(milliseconds);

Good sign somebody doesn't know how threading works. At least they didn't mess up and have it infinite-looping on all CPUs. This bug has been around for forever, luckily common CPUs now have more than 2 threads.

However, I have two steam threads pulling 100%, so I am losing 200% cpu power.

Ubuntu 18.04

[shaolo1]

I saw a fix come through in a recent patch that mentioned something about making idle updates less cpu intensive. Ever since then I've not had the problem again.

[kisak-valve]

Side note for your screenshot @EterniaLogic, htop accounts for the cpu usage by child threads, and the 101% thread is because it's the parent thread and including the 99.2% just below it. Use htop's tree view for this to be clearer.

The system being shown is using 1 core worth for Steam, and 1 core worth for dpkg-deb.

[msimos]

@kisak-valve I've encountered this problem when running Borderlands 2 through Proton. When you exit Borderlands 2, Steam goes to 100%:

From the attached screenshot thread 9151 is causing the issue. And from ps, we see that thread 9151 is CJobMgr::m_Work.

msimos@msi-gs65:~$ ps -T -p 9071 PID SPID TTY TIME CMD 9071 9071 ? 00:03:37 steam 9071 9072 ? 00:00:00 SteamUpdater 9071 9073 ? 00:00:03 CHTTPClientThre 9071 9078 ? 00:00:00 HTMLController 9071 9113 ? 00:00:03 IOCP Thread 0 9071 9114 ? 00:03:13 CIPCServer::Thr 9071 9118 ? 00:00:00 CFileWriterThre 9071 9121 ? 00:00:00 Controller Work 9071 9122 ? 00:00:03 CSteamControlle 9071 9123 ? 00:00:02 CIPCServer::Thr 9071 9125 ? 00:00:00 CIPCServer::Thr 9071 9126 ? 00:00:00 CIPCServer::Thr 9071 9127 ? 00:00:00 threaded-ml 9071 9128 ? 00:00:04 CJobMgr::m_Work 9071 9129 ? 00:00:04 CJobMgr::m_Work 9071 9132 ? 00:00:08 CHTTPClientThre 9071 9133 ? 00:00:04 CIPCServer::Thr 9071 9134 ? 00:00:00 SocketThread 9071 9135 ? 00:00:00 CSteamControlle 9071 9138 ? 00:00:03 CHTTPCacheFileT 9071 9139 ? 00:00:00 gmain 9071 9141 ? 00:00:00 gdbus 9071 9151 ? 00:04:04 CJobMgr::m_Work <--- here 9071 9165 ? 00:00:03 CHTTPClientThre 9071 9217 ? 00:00:03 CHTTPClientThre 9071 9243 ? 00:00:03 CNet Encrypt:0 9071 9244 ? 00:00:04 steam 9071 9246 ? 00:00:03 CNet Encrypt:0 9071 9876 ? 00:00:03 CHTTPClientThre 9071 2324 ? 00:00:00 CFileWriterThre 9071 2594 ? 00:00:00 CHTTPClientThre

[dubigrasu]

I can confirm @msimos findings about CJobMgr::m_Work. I've seen it more than once hogging the CPU indefinitely after finishing a game. The only solution is to restart Steam.

[HeyBanditoz]

I'm getting the same issue, but it's only when a download is running. The download stalls and won't complete.

[Yama-K]

Still an issue. Running steam 1.0.0.61-3 on Arch Linux.

[Leopard1907]

After latest beta update it got worse. For me at least.

https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/1698351414165876179

After mentioned update , now client always keeps one thread busy ;sometimes busy thread is changing. When i look at running processes i see i386-linux-gnu- as a zombie process , a timeout process with this: libasound2.so that comes from runtime again ; CjobMgr::m_work process and last of all this one:

After closing Steam client those three processes stays there:

[TTimo]

Thanks @Leopard1907, can you provide the output on the Help > System Information dialog?

[Leopard1907]

Sure , here.

https://gist.github.com/Leopard1907/15c6e47dfa025df455ae9c3ad63decef

It says " report not available yet" about runtime stuff , normally.

[Leopard1907]

Btw , looks like this always changes between every client restart.

Now it is gstreamer.

[TTimo]

Thanks, that makes sense. So if you run the following:

~/.steam/steam/ubuntu12_32/steam-runtime/run.sh ~/.steam/steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info

You should be getting the same problem - the process or one of it's children will hang. Or maybe it just takes a very long time on your system for some reason? (15-20 seconds would be "normal").

You can disable this check by moving ~/.steam/steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info out of the way for now, it won't really hurt anything.

In order to trace what it might be getting stuck on, can you do:

strace -ff -o srt ~/.steam/steam/ubuntu12_32/steam-runtime/run.sh ~/.steam/steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info

And zip up all the srt.* files that'll come out of it. Since in your case it's hanging you might want to wait about 30 seconds before killing it.

[Leopard1907]

It was 15-20 seconds just before latest client update but this one made it permanent. ( cpu issue )

With ~/.steam/steam/ubuntu12_32/steam-runtime/run.sh ~/.steam/steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info i'm able to get runtime info. Client off and on situations. Running it when client works doesn't solve this problem ( still pegs cpu ) , when client is off ofc it doesn't spawn such processes.

I did strace stuff and it didn't hang.

Here are the outputs:

srt.tar.gz

[TTimo]

Do you have the 'Steam Linux Runtime' installed at all? (e.g. the container runtime) If you do, what happens if you uninstall it, or disable it by renaming it before starting Steam? Do you still get a hanged process?

If you do have it installed, is it actually this command that is causing a hang: ~/.steam/steam/SteamApps/common/SteamLinuxRuntime/run-in-scout -- steam-runtime-system-info ?

[Leopard1907]

Yes, i am using Steam Runtime from compat tools on a native game.

I'm not at home rn but i will ping you when i try what you've suggested.

[dubigrasu]

FWIW I have the same issues as mentioned above by Leopard, issues that started to manifest after the latest beta update.

Before the update (or switching back to stable) there was an aprox 30 secs high CPU usage that eventually would go away. After the update the CPU hang is permanent and I see the same zombie processes after closing Steam.

However I do not have the 'Steam Linux Runtime' installed and moving away the "steam-runtime-system-info" does indeed solve the CPU hang.

Htop reports the "IOCP Thread 0" as the process that hangs. Running the "steam-runtime-system-info" by itself doesn't hang the CPU and the output is instant.

[TTimo]

@dubigrasu sounds good, please see my earlier comment https://github.com/ValveSoftware/steam-for-linux/issues/5493#issuecomment-564795250 and check if you can reproduce the hang and capture it?

[dubigrasu]

Ah, forgot to mention that I tried running through the steam runtime, but couldn't reproduce the hang. Basically I did: LD_LIBRARY_PATH=~/.steam/bin32/ ~/.steam/bin32/steam-runtime/run.sh ./steam-runtime-system-info and it worked instantly.

In any case here's the trace result as instructed above (as mentioned, it did not hang): strace.zip

[TTimo]

@dubigrasu - ok, I'm assuming there is no hang without using LD_LIBRARY_PATH either? (why do you set it in the first place - shouldn't be needed?)

[dubigrasu]

With or without LD_LIBRARY_PATH it still doesn't hang. Setting the LD_LIBRARY_PATH was recommended by a Valve dev to be used when running something through the steam runtime.

[TTimo]

Thanks for clarifying - as long as you use run.sh you don't need to specify anything else.

[Leopard1907]

I don't get hangs with : ~/.steam/steam/steamapps/common/SteamLinuxRuntime/run-in-scout -- steam-runtime-system-info

Output of it is like that:

https://gist.github.com/Leopard1907/fa2f3252f013a779b0c42f765de53d7a

[TTimo]

@dubigrasu are you on Arch as well?

[dubigrasu]

No, Ubuntu 18.04.3 LTS: https://pastebin.com/raw/Fm0DH4Vx

[Leopard1907]

Just an update: I rolled back to stable client and it seems a similar zombie process stuff is also on there but with a difference.

Stable client survives through them after a while , i386 , x86_64 etc it goes like that. And works fine , no more pegs cpu.

On beta ; it can't get past i386-linux-gnu- process.

[priisen]

Same problem on Ubuntu 18.04. Renaming ~/.steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info fixes it.

[davy79]

For what it's worth, having the same issue on ubuntu 18.04.3 steam client: steam-runtime_0.20191210.1 is loading 1 core 100% constantly.

I can confirm that renaming steam-runtime-system-info as suggested removes the constant CPU load.

[XakepSDK]

I think i don't have this problem, i had seen link to this issue in discord. Command ~/.steam/steam/ubuntu12_32/steam-runtime/run.sh ~/.steam/steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info works almost instantly and prints some json, but my user interface starts lagging, mouse twitches until command executed.

[priisen]

Yes, running this from the command line worked for me too (less than a second delay), but as soon as I started the steam UI, one of the CPU cores was sitting at 100% and games were twitchy.

With the file above renamed, the UI doesn't hog a core and games run normally.

[NoXPhasma]

Same happens to me.

https://gist.github.com/NoXPhasma/71109fecedd75e258b976eb3c77999e5

[TTimo]

If you experience the problem of steam-runtime-system-info never terminating, please consider doing the following to help us with diagnosis:

• Check that this only happens when this check is started by Steam, and that running ~/.steam/steam/ubuntu12_32/steam-runtime/run.sh ~/.steam/steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info terminates correctly.

• Replace ~/.steam/steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info by a wrapper script to invoke steam-runtime-system-info wrapped in something like strace -ff -o srt etc.

• You can also attach with gdb and obtain backtraces of which processes are stuck.

If you want to dig deeper, the source to steam-runtime-system-info is available and released under an open source license, see http://repo.steampowered.com/steamrt-images-scout/snapshots/0.20191210.1/

[Tynach]

I think the problem that popped up in the last few days is a separate problem. I never had any of the issues discussed earlier in this thread (stuff from before this comment), but I'm having the 100% CPU usage that started in the last few days.

It might be best to split this off into another issue.

[TTimo]

Here is what we are tracking in this report:

• We are going to move steam-runtime-system-info to execute on demand rather than at startup in an upcoming update to the Steam client. This will resolve concerns of high CPU usage at startup, or at least anything that may have been caused by the tool.

• The steam-runtime-system-info appears to hang on some systems. We would like to identify causes and fix if possible. It's a secondary priority since we are moving the tool away from always being executed.

We do not plan to track any other problems here. Activity before @Leopard1907 started posting information is either outdated or generally unrelated to steam-runtime-system-info - if these issues still happen after the changes we are planning to make for steam-runtime-system-info, please open new issues.

[Leopard1907]

Fwiw i've asked other users too and by looking at activity in this report last few days ; issue seems to be specific to distros with Ubuntu 18.04 base.

[Tynach]

@Leopard1907 That seems to line up with my case as well. I'm on KDE Neon, which is based on Ubuntu 18.04. The real question, however, is if anyone who's on 18.10 or newer is having the same issue.

@TTimo ironically, at least in my case, the 100% CPU usage is gone for the first several seconds of Steam's GUI running. A few times I thought it had fixed itself because I'd go to a few different views (library, store, community, etc.) and it wouldn't come back... Until about 25 - 30 seconds after the Steam GUI appears (I've timed it). At that point, the 100% CPU usage kicks in - but before that everything is fine.

[h3dron]

The issue appeared on my system 2 days ago, I'm on Ubuntu 18.04. The CPU usage is 100% when CJobMgr::m_Work loads. Restarts did't work, Disabling Shader pre-chaching didn't work either, I opted out of beta and the issue was still present. It disappeared once when the new driver updates were installed but after a reboot the issue was back again. Renaming ~/.steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info fixed the problem.

[bzz420]

Same problem noticed here, Linux Mint 19.2, one thread used 100% of the time. Solved it by turning off Remote Play in settings. Hope that will fix that issue for you as well, using Dec 12 compilation, API: v020, steam packet 1576196354

[enrique556]

I am on Mint 19.2 (based on Ubuntu 18.04) and started getting this problem a few days ago. Renaming ~/.steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info fixed the problem.

Check that this only happens when this check is started by Steam, and that running ~/.steam/steam/ubuntu12_32/steam-runtime/run.sh ~/.steam/steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info terminates correctly.

Correct.

Replace ~/.steam/steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info by a wrapper script to invoke steam-runtime-system-info wrapped in something like strace -ff -o srt etc.

This also fixes it - I can confirm that the renamed steam-runtime-system-info.disabled is being called by the shell script named steam-runtime-system-info, and it terminates after a few seconds. This occurs about 5 seconds after I start steam.

[BETLOG]

Same problem on Ubuntu 18.04. Renaming ~/.steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info fixes it.

Same. I was getting one core running at 100%, even after exiting steam. Manifested in BFBC2 as smooth mouse motion always being jerky, and GPU (or maybe CPU) fan still thrashing at 100% even after game exit. Seems to have been fixed with:

mv ~/.steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info  \
~/.steam/ubuntu12_32/steam-runtime/amd64/usr/bin/NOT_steam-runtime-system-info

[edit] Correction. It seems to stop steam from using all of one core, but after a few minutes play my mouse movement is choppy again.

[NoXPhasma]

Correction. It seems to stop steam from using all of one core, but after a few minutes play my mouse movement is choppy again.

This is most probably an issue with Proton 4.11-10 and not related to this. You can revert to 4.11-9.

[BETLOG]

This is most probably an issue with Proton 4.11-10 and not related to this. You can revert to 4.11-9.

Thanks. [edit] removing the dumb and the tl;dr