Prevent Zoom from consuming all your CPU on Linux | Hacker News Reader

Prevent Zoom from consuming all your CPU on Linux

gist.github.com

63 pointsnixcraft54 comments

I don't permit Zoom to run on my Linux desktop, too sketchy. Instead I use their web ui, which runs in the relative safety of my firefox container.

That's not really a container though, Firefox by default has a wide-range access. As someone who has to use Zoom, I use firejail, which is a true container, super easy to use and comes with a profile for Zoom out-of-the-box.

To set it up, just create a symlink once

   # ln -s /usr/bin/firejail /usr/local/bin/zoom

and you should be all set (assuming that in your PATH, /usr/local/bin comes before wherever the real zoom binary is, more details on firejail: https://wiki.archlinux.org/title/firejail#Using_Firejail_by_...)

In my case, I also have a ~/.config/firejail/zoom.local file with the contents

   whitelist ${HOME}/Documents/Zoom/
   noblacklist ${HOME}/Documents/Zoom/

to fine-tune access for storing chat logs under the default path.

It is also very easy to sandbox X11 access with firejail (which uses Xpra or Xephyr), but I only have Zoom running when I use it, and I often need share my screen, so I don't enable it.

I found the video quality and responsiveness to be far worse, and I have to teach and work over Zoom. I tried running the desktop client virtualized as well, with similar results.

So… sketchy it is. I find myself wondering what it’s doing with 15% CPU when not in a meeting. Feelsbad.

I ran it under strace and after that it was never allowed to run again. I don't know exactly what it's doing, but it's nothing I want it to be doing.

If you get an AMD GPU then the web experience is a bit more performant, the Intel iGPUs are not quite potent enough.

Mind if you elaborate on that? I just ran zoom with strace but see nothing out of ordinary.

Discreet GPUs support encoding/decoding a lot more streams than the integrated stuff. Depending on the generation of Quicksync you have, the codec used by Zoom might not be hardware accelerated at all, though I think Zoom uses h264, so you'd have to be on some pretty old hardware.

I don't know about zoom specifically, but most video conferencing programs counterintuitively don't use hardware video encoders/decoders.

They use the GPU for visual effects (background blur etc), but then do regular CPU video encoding. That's why they gobble so much CPU!

I think that helps with system compatibility. Hardware video encoders are full of bugs and corner cases, and it's very easy for someone to end up seeing a garbled image when the bitstream was truncated or bad in some way.

Is there something specific about the AMD drivers? I have a decent Nvidia card (I know, I know…)

Have you tried running the desktop client in a container? Lots of options for this on Linux.

There shouldn't be any significant virtualization penalty. My guess is that it uses hardware video codec acceleration and that wasn't accessible in the VM you had set up? If the guest was Windows, looks like nvidia has supported this since host driver version v465 or later.

https://nvidia.custhelp.com/app/answers/detail/a_id/5173/~/g...

HTH!

The systemd slice approach is the same mechanism as containers.

The security problem is being able to talk to the same X server as trusted applications. X clients can do pretty much all the things you don't want Zoom to do; look at your screen, observe your keystrokes, etc. (Sadly, many of Zoom's features, like screen sharing, are also great things for spyware to do in the background. Not saying Zoom does this, but if you don't trust them, this level of access is the part that worries people, not consuming too much CPU.)

> The security problem is being able to talk to the same X server as trusted applications

Use Ctrl+Alt+F<number> to switch into another VT and run a different X server. Run zoom in container there.

I found this a lot more convenient than messing with nested X servers and other types of X11 client isolation. Each time you leave an X server and switch to another VT, the clients perceive it like the monitor being turned on/off.

Thank you for this, easy solution that didn't cross my mind. I wanted to restrict Zoom from reading files (solved by a sandbox) while also sharing my screen from my normal environment (VM is out of the picture) but also preventing it from looking at the X clipboard and all that stuff.

I did, but had trouble getting it to work. It was a while ago though, and the image I was working from was old/unmaintained even at the time. Linux guest. Do you have any examples to hand?

Why run it when not in a meeting?

I do kill it, but I’m in and out of meetings all day, so it’s easy to forget.

How do you use the web UI?

When you get a link to a zoom call, instead of permitting it to open a handler program or clicking Join Now, click the link that says

> Having issues with Zoom Client? Join from Your Browser

https://chrome.google.com/webstore/detail/zoom-redirector/fm...

I just use this. I'm assuming that is what you're asking about.

I don't use that, since I'm not using Chrome, but it looks handy.

you do know that any browser extension you use has a cleartext view of all your web content (on that browser).

I fear the day that UBlock Origin ends up with an exploitable bug. It's so damn common, but the web is nearly unusable without it.

They use dark patterns to hide the web version so that you download the client. I fear they'll yank the plug on the web version one of these days...

and that will be the last Zoom meeting I ever attend.

I recently uninstalled the desktop version due to how broken it is on Wayland.

To give credit where due, their web client has improved a lot over time, so now it is a legitimate replacement. (Apart from the nag screen to use their desktop version. It would also be great to have it as a separate PWA though rather than a tab, I should look into that)

I unset WAYLAND_DISPLAY when running Zoom’s desktop client, to make it use X (thus XWayland). This fixes the crash-on-meeting-join problem it’s had for some months now, theoretically at the cost of screen sharing, but as a Sway user that was already not working, as they only support GNOME rather than using xdg-desktop-portal like everyone else.

Brilliant! I hadn't been able to find a solution for that one! (I'm still gonna stick with the web version for now since that way I can screenshare, but good to know there's a solution to one of my issues)

my main gripe with zoom on linux (besides being forced to use it at all) is that it sets my microphone volume to 0 every time i join a new meeting or breakout room

I had that. Under Settings -> Audio there's a setting "Automatically adjust microphone volume". It used to happen to me on Windows as well.

I had this problem as well. I eventually found a setting to title which for zoom to leave the mike alone. Check you settings...

To title which for zoom did you setting to leave the mike alone?

That's what I get for not proofreading for autocorrect errors

This happens to me all the time too. Seems to happen even when just muting / unmuting.

Now do this for MS Teams on Linux (wasn't my decision).

Try https://teams.microsoft.com. 99% of the app functionality - basically no virtual backgrounds. No install. Works as a PWA too.

I had issues so now I do it in microsoft edge on linux and it's been fine. Yeah, microsoft's browser is on linux, wild times... it's their first browser on *nix since IE 5.0 SP1 in 2001.

I remember having a Sparc Ultra 5 that I used remote X with to run IE5 on my linux system at the time for those sites that absolutely insisted that I used IE and wouldn't work with NN. Fun times ... actually no, that kinda sucked.

This is a hell of a long way to just say `taskset -c 0-4 ZoomLauncher`.

It doesn't just set CPU affinity, it also defines a memory usage ceiling for the application beyond which it gets throttled.

Oh cool! So, does that update this file, too, so it always does it this way? Or?

I'm definitely not familiar with the tricks they're doing here. Looks like an ini file!

It's: taskset <arguments> <command to run>

So to run `ls ~` on only cpu0 you would run:

taskset -c 0 ls ~

Run it each time you want to invoke the command.

It seems like the article itself updates the icon on the desktop to always use those specific processors, though, right?

that's true -- but given that not all desktop environments respect the idea of *.desktop , and not all distributions use /.local/share, so , pedantically, the parent that suggests 'taskset -c 0-4 ZoomLauncher' suggests a tip that will work on just about every linux distribution, however the git snippet that was linked as the parent of this thread will only work on a handful of distribution/desktop-environment combinations.

tl;dr : parent to your comment suggests a more generalized 'for linux' solution that doesn't depend on specific flavor nuances and desktop environs.

(user 10000truths has a good point, it sets memory ceilings as well -- this should still be done in a way that is distro-agnostic.)

For platforms where you are running things via the command line rather than via the .desktop files, you could run this in a few different ways:

  gtk-launch Zoom

  gio launch ~/.local/share/applications/Zoom.desktop

  systemd-run --user --slice=zoom.slice /opt/zoom/ZoomLauncher

Perhaps alias `zoom` to one of these, or create a shell script that execs one of those and add it somewhere higher in your path than /usr/bin.

Can someone enlighten me on what actually happens? I run zoom (desktop client) everyday for short standups and hour+ long architecture/tech discussions and code reviews, and I've never really noticed the CPU usage?

(Linux Mint 20 with 5.14.12-xanmod1 on a t480s, which reminds me I need to reboot since I have 5.14.18 installed and waiting...)

I wish I knew. When I run Zoom on a Windows i5 with 8gb of ram it tells me I need to close other applications in order to free up resources.

If I run Zoom on Mac, I find that once a week, I have to reset my PRAM. If I don't, my Mac freezes for a few seconds whenever I use the volume up/down buttons, or whenever I screen share on Zoom.

I don't know if it still does this but Zoom used to just preemptively murder coreaudiod at startup. Which was not ideal, to say the least. I assume this is also why it sketchily reads all process names at startup on Linux: it is trying to find and destroy pulseaudio.

Really, there's no reason to permit the Zoom application to get anywhere near your computer. Just run it in a web browser.

Like everyone else here, I refuse to run Zoom.

Web client if it cant be helped.

PSA: AllowedCPUs only works with systemd.unified_cgroup_hierarchy=1. Until Docker 20.10 you needed unified_cgroup_hierarchy=0, and Ubuntu just switched in 21.10.

Best way to do this is to keep their software of your machine and use the web client

I’d love to do this, but the web client is (as of a month or two ago) missing “grid view,” which makes it useless to me for team meetings. Seeing everyone at once is very nice

Grid view works in Chrome but not Firefox.

I wonder if it will work in Firefox if you change the useragent string to one that pretends you're using a Chrome browser

Chrome has some APIs that Firefox doesn't; for example, Jitsi video conferencing supports e2ee videoconferencing on chrome, but not Firefox, due to Chrome having an API that let them do the manipulation on the video stream after it hits the client (I think. My memory is fuzzy.)

The aristocrats!

All jest aside though, I wonder how long this type of thing will continue, or if Chrome will just consume all.

Reply on news.ycombinator.com