Same for me. Gentoo/amd64. Update: steamwebhelper uses 100% of one CPU core.

Actually I don't open two Steam clients in different user sessions, I open only one but using "kdesudo -u me-steam steam" (/etc/sudoers contains appropriate entry so I'm not asked for password). Steamwebhelper starts loading CPU at the moment I click desktop icon, i.e. long before Steam shows me "Connecting Steam account: ..." But this does not happen every time I start Steam, could not determine pattern.

Same here on debian testing, open a steam session, then close it, log out of gnome, log in as another user, open up steam session (also another steam user aside from the first one), then steamwebhelper consumes 100% CPU (*of a single core):

13468 josh      20   0  305600  38864  34232 R  97.6  0.3  33:55.31 steamwebhelper      

uname -a for kicks:

josh@MSIGS70stealth:~$ uname -a
Linux MSIGS70stealth 3.16-2-amd64 #1 SMP Debian 3.16.3-2 (2014-09-20) x86_64 GNU/Linux

Same problem here. Running Linux Mint 17 with Cinnamon desktop. If I close Steam, log into another account and then open Steam from inside that other account, my CPU use spikes to 50% due to steamwebhelper.

Weird, I've never met the problem since my last comment. (Actually, I wrote "could not determine pattern" because at the moment of writing I started Steam again and it was OK for the first time in a while.) Maybe some system library upgraded which steamwebhelper relies on, or I rebooted after earlier upgrade, I don't know.

up to date on Debian testing (jessie) and I can duplicate the issue every time

Same issue here on Xubuntu 14.04. Starting and closing steam in one session, logging out, and then logging into another session and trying to start steam there will make steamwebhelper max out one core of my cpu.

Rebooting instead of just logging in and out fixes this issue.

I had the same issue just now, and can confirm what martinfischer said in previous comment.

Based on previous comments, I guessed it might be something in /tmp, and found how to fix it:

sudo rm /tmp/steam_chrome_shmem

before starting steam for the 2nd user.
It's a unix domain socket. Ideally steam would use different filenames for different users.

sudo rm /tmp/steam_chrome_shmem

This looks right. I recall I had issues only during transitioning steam from my main account to separate one (kdesudo, call me paranoid). Issue disappeared only after I stopped starting steam under my main account.

sounds like this file should be a singleton lock perhaps. I can't imagine more than one user utilizing the video card at once.... Perhaps on some sort of strange video game server that had multiple players logging in like terminal clients back in the day.... hmmmm, well ok, that sounds kind of cool. Don't make it a global singleton and give it a unique identifier of some sort to not conflict with other users, perhaps steam_chrome_shmem_$USERNAME

What version contains this fix? The broken behavior persists on Debian Testing.

Current steam beta (2014-11-18) generates /tmp/steam_chrome_shmem

@Linuturk @Tele42 Same here, I'm opt'ed in on beta, with Steam package version: 1416350232

I imagine they have not rolled this fix out to the public yet?

$ ls -lh /tmp|grep -i steam
srwxr-xr-x 1 bob  bob     0 Nov 19 10:32 steam_chrome_shmem

Thanks Josh Cox. Changing the ownership of the steam_chrome_shmem file
does solve the problem although it needs to be done every time when logging
into a client on another account. I guess it's a temporary fix but it's
works for now.

On Thu, Nov 20, 2014 at 1:38 AM, Josh Cox [email protected] wrote:

@Linuturk https://github.com/Linuturk @Tele42
https://github.com/Tele42 Same here, I'm opt'ed in on beta, with Steam
package version: 1416350232

I imagine they have not rolled this fix out to the public yet?

$ ls -lh /tmp|grep -i steam
srwxr-xr-x 1 bob bob 0 Nov 19 10:32 steam_chrome_shmem

—
Reply to this email directly or view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/3514#issuecomment-63680332
.

I use Fedora 19. Had the same. Solved it.

Start steam with the steam.sh script from terminal window.
(Example:
/home/username/.local/share/Steam/steam.sh)

See if modules and/or libraries are missing (or theme as in my case)
on your system. On mine the bold stuff was missing:

(steam:4602): Gtk-WARNING : Unable to locate theme engine in module_path: "adwaita",
Gtk-Message: Failed to load module "pk-gtk-module"
Gtk-Message: Failed to load module "canberra-gtk-module"
/home/username/.local/share/Steam/ubuntu12_32/steamwebhelper: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory

It's just some packages that have to be installed (Note: the 32 bit ones, so with .i686
behind the package name and not .x86_64 because steam is 32 bit)

On Fedora, installing the following packages solved all the error messages
(solving all the above errors from top to bottom):
adwaita-gtk2-theme.i686
PackageKit-gtk3-module.i686
libcanberra-gtk2.i686
libcanberra-gtk3.i686
GConf2.i686

I think installing the last one solved it, but i'm not sure if it's a combination
with one of the others.

If you use another Linux distribution the packages probably are named a little different.
Just search on different keywords per package.

@TrIPpY- I am not certain you had the same issue, specifically in this instance steam puts a file steam_chrome_shmem in /tmp, when you log out of your current user and log in as another user and then start steam, steam then starts consuming 100% of one of the CPU cores. I think the accepted solution is for that file to be named uniquely e.g. $USERNAME_steam_chrome_shmem which @alfred-valve has indicated should be coming down to us civilians soon. @alfred-valve is this still true?

Yep it's true. Same result by different problem. Well i'm 80% sure it was the webhelper causing my 100% cpu core usage (because of the error message specifically saying libgconf-2 is missed by it and it was the last thing installed before the problem was solved (The people, earlier reporting 50% cpu usage (by the process) probably have a dual core system).

I written my solution here because (very probably) the webhelper caused the high cpu usage and i know how fierce they are on forums and such, to not start a new thread if a similar one exists already.

I also tested logging on as another user (as the rest did, written in the earlier posts) and have the same. Delete the steam_chrome_shmem file in /tmp and no high cpu usage.

NB: addition to my previous post for Fedora users: It might be the problem only occurs with the steam_noruntime package (as i have).

possibly, but I do have libgconf here, maybe a version mismatch though or something:

> sudo aptitude search libgconf-2
[sudo] password for bob: 
i A libgconf-2-4 

I think that package is the debian equivalent of Fedora's GConf2.i686 package hence the filename libgconf-2.so.4 which it provides. Strong similarity i'd say.

Just to clarify. I only run Steam under one Linux user. After a Steam update sometime ago it got real slow. Due to this topic i found out that was because of the 100% cpu core usage (reminded me to check that).

@sswam: Thanks a boat load for that tip! This bug was driving me bonkers - the workaround is fiddly, but is a lot better than a useless steam. Here's hoping the fix gets pushed soon.

Had the same problem just now.

Steps to reproduce:

1. Create a new user
2. Logout the current user
3. Login as the new user
4. Start steam

It downloads and installs the runtime, etc. After that 100% CPU and a unresponsive Login GUI.

What helped:

1. Delete /tmp/steam_chrome_shmem
2. Reboot

Just deleting steam_chrome_shmem was not enough. Got the same problem. Only a reboot helped. Maybe because of some other files in /tmp that got deleted on reboot.

Are you opted in the Beta?

Nope. No Beta.

I'am wondering why someone from valve said in Nov 2014 "The last steam release changed the filename to include username in it.", which is not the case here.

Can you try opting into the beta? This should have the filename change and a fix for the hangs.

Ok. Its in Beta now and this seems to be fixed there.

Regular steam client: steam_chrome_shmem
Beta steam client: steam_chrome_shmem_gaming_spid2314

Then its just a long beta phase.

I'm still having this issue today, on Ubuntu.
It makes cpu-intensive games unplayable on my system, unless I use cputool to set the load allowance to something low, like 1%, for the steamwebhelper pid group.

As I found this issue while googling a different issue with the steam client, I just figured I'd post the above fix, for anyone else stumbling over this through google etc.

This is still a problem with the latest version of steam on Ubuntu 22.04 Jammy Jellyfish.