Running a Current Zoom Package on 32-bit Debian

[There's a TL;DR at the end of this rant in case you're just desperate to get your Zoom client to work again]

There are many reasons why proprietary, non-interoperable services are a bane and why I generally say no to them, be them Twitter, Discourse, or Google Docs. However, I regrettably cannot say no to Zoom, even though there are perfectly Free alternatives like, say, mumble plus perhaps VNC if you need screen sharing. Still, just about everyone simply expects you to cope with this heap of proprietary lock-in. Granted, at least it doesn't require downloading and running ridiculous amounts of Javascript code into your web browser each time you run it like some other telecon systems I could mention (including Free ones).

Upgrade now! But… to what?

And one has to give the Zoom client that its audio interface used to be a lot better than what today's major browser vendors have to offer (minor browsers can't run the telecon crapware anyway).

One strong reason to say no even to Zoom, however, is the feeling of helplessness when the software depends on a central server and that server suddenly locks you out. That happened to me with Zoom last week, when the damn thing started to say “you need to upgrade to connect to this conference” or something to that effect.

After I have been running the probably multiply exploitable, ugly binary package for perhaps two years without ever upgrading (Zoom doesn't operate a proper repository, and hence there's no apt-upgrading it), that was not unreasonable per se. Except that even manually pulling a .deb from Zoom's Javascript-infested web pages did not help. Umm, what?

It turns out that the Zoom folks do not bother any more to update their 32-bit package and simply distribute the 5.4.whatever that they're locking out. No amount of installing that changed Zoom's refusal to let me into the conference, and working with the telecon host to see whether any setting in the management interface would let me in again went nowhere. It is this feeling and fact of infant-like helplessness that I so detest about being forced into proprietary technologies.

How great would it be if Zoom were proper Free software and I could build this myself? How even greater if it were built on open standards and I could just switch to an alternative client? Or cobble together my own?

But no, I had to eat dirt. I fetched the 64-bit version and dpkg -i-ed it. I had already run:

dpkg --add-architecture amd64

on that box a long time ago, so I figured Debian's dependency resolution magic should cover the rest. How wrong I was.

Typing zoom after dpkg -i zoom-amd64.deb followed by apt install -f to satisfy dependencies brought back the command prompt right away – but not zoom window. The program just silently crashed. What?

In such a situation, the first thing I do is run strace to see what syscalls the program does before dying. However, the output made no sense at all, starting with chdir(0x01). This would have to immediately crash (there certainly is no path name at the memory address 1), but the strace of Zoom instead went on for a few pages. Hu?

After having been stumped for a few minutes, it dawned on me that stracing an amd64 binary will plausibly require an amd64 strace, so I typed:

apt install strace:amd64

and tried again. This time, strace's output made a lot more sense, and right before dying, it said:

stat("/usr/lib", {st_mode=S_IFDIR|0755, st_size=32768, ...}) = 0
writev(2, [{iov_base="/opt/zoom/zoom", iov_len=14},
 {iov_base=": ", iov_len=2},
 {iov_base="error while loading shared libraries", iov_len=36},
 {iov_base=": ", iov_len=2}, {iov_base="libpango-1.0.so.0", iov_len=17},
 {iov_base=": ", iov_len=2}, {iov_base="cannot open shared object file", iov_len=30},
 {iov_base=": ", iov_len=2}, {iov_base="No such file or directory", iov_len=25},
 {iov_base="\n", iov_len=1}], 10) = 131

In other words: It tried to load the pango library (which draws text strings in Gtk and elsewhere) but failed. What? I installed this from a Debian package and it has not noticed the dependency?

Well, the Zoom folks clearly got it wrong and fooled the machine into accepting the 32-bit libraries (which of course are already on the box) for 64-bit dependencies, which simply cannot work. I am not going to do research for a commercial entity and hence just gritted my teeth. Repeatedly letting the thing crash, I eventually figured out that I need to manually say:

apt install libxcb-keysyms1:amd64 libglib2.0-0:amd64\
  libxcb-shape0:amd64 libxcb-shm0:amd64 libxcb-xfixes0:amd64\
  libxcb-randr0:amd64 libxcb-image0:amd64 libfontconfig1:amd64\
  libgl1-mesa-glx:amd64 libegl1-mesa:amd64 libxi6:amd64\
  libsm6:amd64 libxrender1:amd64 libpulse0:amd64 libxcomposite1:amd64\
  libxslt1.1:amd64 libsqlite3-0:amd64 libxcb-xtest0:amd64\
  libdbus-1-3:amd64 libxtst6:amd64 libxcb-xinerama0:amd64\
  libxkbcommon-x11-0:amd64 desktop-file-utils:amd64\
  libgbm1:amd64 libdrm2:amd64 libfreetype6 libatk-bridge2.0-0:amd64\
  libxrandr2:amd64 libpango-1.0-0:amd64 libcairo2:amd64\
  libcups2:amd64 libnss3:amd64 libxdamage1:amd64

to have the damn thing at least not crap out during startup. What, if I may ask, does it need cups for?

Alas, that's still not good enough. While Zoom at least did not immediately terminate any more, it still did not properly connect either. This time, strace -f-ing ends with:

5783  poll([{fd=3, events=POLLIN}, {fd=13, events=POLLIN}, {fd=14, events=POLLIN}], 3, 0) = 0 (Timeout)
5783  poll([{fd=3, events=POLLIN}, {fd=13, events=POLLIN}, {fd=14, events=POLLIN}], 3, 14995 <unfinished ...>
5789  <... futex resumed>)              = -1 ETIMEDOUT (Connection timed out)
5789  futex(0x7fa62a77b4d0, FUTEX_WAKE_PRIVATE, 1) = 0
an then a lot of
5789  +++ exited with 0 +++
...
5783  +++ exited with 0 +++

Oh great. A successful exit even though the program failed. The joys of commercial software development.

But be that as it may: it is failing because whatever should be feeding file descriptor 3 apparently is not fast enough. The question is: what? Well, let's see what this file descriptor 3 is. In my vi, I'm grepping through the strace protocol for a call in process 5783 returning three like this:

?5783.*= 3$

and I find:

5783  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3
5783  connect(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, 20) = 0

Oh dang. The thing is waiting for the X server when it dies? Why would the X server time out? Spoiler: That I have not found out. But quite close to this I saw that Zoom also opens the file ~/.zoom/zoom_stdout_stderr.log and dumps the messages I was missing on stderr there. In fact, I could have gathered the missing libraries from that file rather than strace had I known about it.

What did I find in there? Well:

ZoomLauncher started.
Zoom path is: /opt/zoom
cmd line:
Start subprocess: /opt/zoom/zoom sucessfully,  process pid: 5916
sh: 1: pactl: not found

This looks almost as if it needs pulseaudio? But what about the timeout on the X socket? I don't know, but I can report that installing pulseaudio-utils did fix the pactl failure (if you want to call it that), but it still did not make the thing run. At least according to strace:

7193  execve("/bin/sh", ["sh", "-c", "pactl --version"], 0x7ffd6d009b08 /* 38 vars */ <unfinished ...>
...
7193  <... execve resumed>)             = 0

it's not because pactl would fail, though frankly it would seem a bit odd that Zoom is calling an external binary in the first place and then go through the shell on top – what's wrong with execve and friends? Zoom, however, still exits on the X timeout:

7223  poll([{fd=3, events=POLLIN}, {fd=13, events=POLLIN}, {fd=14, events=POLLIN}], 3, 14994 <unfinished ...>
[...]
7223  <... poll resumed>)               = 0 (Timeout)

At this point, I seemed to be at a dead end: do I really want to debug whatever Zoom's Qt basis had to work out with X11 that would make X11 fail that dramatically?

On a wild guess, I suspected some stale setting now that I had noticed there is a .zoom directory. I hence moved that away. Lo and behold: suddenly the messages so far hidden in .zoom arrived on stderr. And it now said “No PulseAudio daemon running, or not running as session daemon”. Aw, bother. That the Zoom client properly dealt with plain ALSA was, frankly, one of the reasons I sort of gave in to zoom. That's now over, too.

I sprinkled the box with a bit of holy water (something to the effect of pulseaudio --start), and zoom finally came up and connected to their nasty, proprietary server that had locked me out with the 32-bit client.

Too long; didn't read

So… If you're in the same situation as a was and Zoom's servers lock you out: I'd hope that installing the extra libraries and pulseaudio and then moving the .zoom subdirectory out of the way – I'd probably not remove it altogether immediately, as it might contain credentials or a Zoom bitcoin wallet or whatever – might very well get you back into the next boring and suprerfluous telecon.