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などで参照する。出てくる変数をその値とともに一覧にすると、

変数
$0 teams
$SCRIPT /usr/bin/teams
$USR_DIRECTORY /usr
$TEAMS_PATH /usr/share/teams/teams
$@ /usr/bin/teams 実行時の全パラメータ

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の問題と納得できる。

日時 Debian Ubuntu 解説
2020-10-06 20:33 Upgrade to: 1.3.00.25560
2020-10-19 16:46 Install: 1.3.00.25560 f ダウンロードしたファイルから導入
2020-12-08 02:42 Upgrade to: 1.3.00.30857
2020-12-09 10:24 Upgrade to: 1.3.00.30857
2021-03-08 19: 問題なく接続 使用せず
2021-03-09 10:54 Upgrade to: 1.4.00.4855 この1.4.00.4855が問題であったらしい
2021-03-15 19: 接続不可 試していない
2021-03-15 19:16 Purge:1.4.00.4855 一旦削除して
2021-03-15 19:35 Install:1.4.00.4855 入れ直したが接続不可
2021-03-22 13:00 Upgrade to: 1.4.00.4855 次回はUbuntuを使おうと用意。Upgradeをしたのが失敗
2021-03-22 19: 接続不可 接続不可
2021-03-25 19: スクリプト書き換えして成功 (特別に会議を用意してもらって試行)
2021-04-01 17:55 Upgrade to: 1.4.00.7556
2021-04-18 08:45 Upgrade to: 1.4.00.7556 このUpdateで書き換えたスクリプトは消失