[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?
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?
In the meantime, there are two extra packages zoom wants to see, so
I added these, too.
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 …