Microsoft Teams 会議に参加できなくなったのは

Microsoft Teams linux用にミス

2021年3月15日に毎週参加していた会議に参加できなくなった。Linux上のTeamsを使っているのは私だけ。

ブラウザでは承認を受けるまでは行き、一瞬つながって認証の問題で切れるらしい。普段使っているアプリでの接続では認証の段階までも行けなかった。

これはバージョン1.4.00.4855の問題で、起動スクリプトが間違っていた。現在のバージョンは訂正されていて問題は起きない。

今はこの問題は簡単に検索で見つけられるが、当時ひとつだけ出ていたものを見つけて解決した。

記事の引用

当時、見つけたページは記録していなかった。現在見つけられるページでわかりやすいのはここ。

https://docs.microsoft.com/en-us/answers/questions/46206/teams-linux-desktop-app-wont-launch-when-joining-a.html

 KhizerNaeem-7888 · Mar 16 2021 at 5:20 PM 
I was also facing the same issue after teams got upgraded to teams-1.4.00.4855-1.x86_64. After some research I found the solution.

Basically there is a mistake in the teams startup script located at /usr/bin/teams. Edit this file and replace

    nohup "$TEAMS_PATH" --disable-namespace-sandbox --disable-setuid-sandbox "$@" > "$TEAMS_LOGS/teams-startup.log" 2>&1 &

with

    nohup "$TEAMS_PATH" "$@" --disable-namespace-sandbox --disable-setuid-sandbox > "$TEAMS_LOGS/teams-startup.log" 2>&1 &

Basically moving "$@" right after "$TEAMS_PATH" instead of at the end.

This resolved the issue for me.

書き換えろというteamsを読む

この /usr/bin/teams は起動スクリプトで、本体のプログラム /usr/share/teams/teams を呼び出すように書かれている。

#!/bin/sh

SCRIPT=$(readlink -f "$0")
USR_DIRECTORY=$(readlink -f $(dirname $SCRIPT)/..)

TEAMS_PATH="$USR_DIRECTORY/share/teams/teams"
TEAMS_LOGS="$HOME/.config/Microsoft/Microsoft Teams/logs"

mkdir -p "$TEAMS_LOGS"

nohup "$TEAMS_PATH" "$@" --disable-namespace-sandbox --disable-setuid-sandbox > "$TEAMS_LOGS/teams-startup.log" 2>&1 &

TEAMS_PATHなどは変数。$TEAMS_PATHなどで参照する。出てくる変数をその値とともに一覧にすると、

nohupはコマンドシェルが終了してもコマンドの実行が停止されないようにするもの。"$TEAMS_PATH" がそのコマンドで、"$@" と --disable-namespace-sandbox と --disable-setuid-sandbox は、コマンドに渡すパラメータだろう。$@は呼び出すコマンドにつけられていたパラメータの全体で、これをそのまま引き渡すためにある。

つまり、仮にパラメータが"-a -b -c"で、

teams -a -b -c 

と/usr/bin/teamsが呼び出されたら、

/usr/share/teams/teams -a -b -c --disable-namespace-sandbox --disable-setuid-sandbox

としたいということ。

パラメータの順序が違うだけで動かなかったということになる。

原因となったバージョンの検証

Debian/Ubuntuではアップグレードの記録が残る。最近は自動でアップグレードの通知が入ったりするが、基本は時間に余裕があるときにアップグレード操作をするのがlinux流。したがってアップグレードの日時はDebian/Ubuntu側の日時とは異なる。両方のアップグレートの日時と、バグを踏んだ日時とすり合わせてみる。

確かにバージョン1.4.00.4855の問題と納得できる。