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.
この /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で書き換えたスクリプトは消失 |