2024年2月3日土曜日

Visual Studio Codeのアップデート後に、SSH接続ができなくなった時のこと

article_240204

Visual Studio CodeでサーバーへのSSH接続ができなくなる

昨日までVS codeを使って問題なくSSH接続をしてサーバーを利用していたが、今日これまでと同様の方法で利用しようとしたときに接続できなくなっていることに気がついた。以下のようなメッセージが表示された。

# The remote host may not meet VS Code Server's prerequisites for glibc ...

検索してみると、VSCodeでSSH接続できない原因は様々あるようだったが、上記のようなメッセージから、ホスト側サーバーのライブラリに原因があるようだった。VSCodeを起動させたときに、アップデートのREADMEが表示されたことから、おそらく前日に使用していた時からのアップデートによって、問題が生じたのではないかと考えられた。メニューのaboutで表示してみると、最新バージョンにアップデートされていて、Version 1.86だった。その前のversionは、November 2023の1.85.2であるよう。

Visual Studio Code Updates

VSCodeを前のバージョンにロールバック

サーバー側の対応ではなく、VSCのロールバックによりとりあえず環境を回復することにした。上記のリンクから1.85のインストーラーをダウンロードして起動、指示にしたがってインストールを進めた。途中に出てくるデスクトップアイコンの作成や、パスの追加等は選択しなかった。ウィザードが完了した時点で、元からあったアイコンからVSCを起動すると、無事にバージョンがロールバックされていることが確認できた。また、extensionや設定等は元の状態のままであることも確認できた。SSH接続を再度試行すると、今度は問題なく接続できることがわかった。

自動アップデートの設定を変更

接続の問題は解決したが、VSCodeが再度自動でアップデートされないように、Settings からupdateの設定をNoneに変更することにした。以下の画像中の黄色い矢印で示した通りに、settingsからupdateを検索し、auto updateの設定をnoneに切り替えた。

settings

プラットフォームになっているもののversion updateに注意する

比較的簡単に以前の状態に復旧できたが、時間がないときに通常状態の環境が使用できなくなることは痛手になりうる。condaの時にも感じたことであるが、様々なことのプラットフォームになっているアプリケーションやOS等は、周りの互換性も問題になるので、なるべく管理され計画された形でUpdateをかけた方が良いことを再認識した。ルーティーンの中にそういったupdateを計画、実施する時間も組み込んでいることが望ましいのだろう。

2024年1月7日日曜日

問題の生じたconda環境のロールバックによるレストア

New Post:

conda環境で発生した問題

python環境設定、及び各種解析のためのアプリケーションの管理のためにmimiconda3 & conda-forge channelを使用しているが、しばらく前からなかなか解決しない依存性の問題を抱えてしまい、困っていた。症状としては、conda をアップデートすることも、新しく環境をcreateして必要なpackageをインストールすることもできず、現存する環境のみ使用できるような状況にほぼ近い感じになっていた。conda update -n base -c conda-forge condaをしようとしても、An unexpected error has occurred.でレポートが作成されて、updateができない状態であり、下のリンクに近い。

調査していくと、condaをアンインストールしてまた再インストールする手順等が比較的出てくるような気がした。万が一バックアップやレストアに失敗すると影響が甚大なので、手をつけるのが億劫になっていたが、conda周りの解析環境整理と再構築を実施することにした。

以下の手順が最適なものかは分からないが、依存性でcondaが問題を抱えてしまいアップデートも新規導入もできなくなってしまった際の再構築した記録として記載したい。

解決のための手順

上述したように、問題はupdateをかけた時に、unexpected errorでアップデートも新規package installもcreate environmentも期待通りに実施できないことである。condaを一度uninstallして、再度installし、バックアップしておいた旧環境のenvを再構築すれば良いかもしれないが、万が一レストアできない状況になることを考え、極力uninstallのステップは踏みたくない。これに対して、大まかには以下の手順で問題の解決を試みた。

  1. 現在のenv含めcondaの環境、.condarc、.bashrcの記述、その他condaに関連するファイルのバックアップを実施する。
  2. conda install --revision=REVNUMによるロールバックを実施し、問題がなかった頃のrevisionに戻る。
  3. conda install conda=VERSIONにより、condaのバージョンを上げる。
  4. condaによる環境設定が再び可能になったかを確認。
  5. 今回の問題を引き起こしたと考えられる(base)環境での依存性に関係した問題(?)を引き起こさないために、baseは新しいpackage等を導入しないようにして、analysis用の別の環境を構築する。

1. バックアップ

ホーム下でcondaに関連する.condarcの記述、隠しディレクトリ.conda下の内容、等々をbackup dirに保存したほか、ymlファイル等をそれぞれの環境で作成して保管した。HOME下にある.condarcには、

channels:
  - conda-forge
pkgs_dirs:
  - /path/to/modified/package/dirs/pkgs

また、フォルダ.conda下には、entironments.txtがあり、構築してある環境のpathが格納されている。.bashrcには、conda initializeの記載がインストール時に記載されている。特にバックアップする必要はないと思ったが、現状の記録のために保存した。

Revision情報

パッケージの導入、アップデート、削除等の情報をconda list -n ENV --revisionsで見ることができる。今回のinconsistencyの検証のために閲覧し、今後問題を見返したくなった時のために、環境ごとにテキストファイルで保存した。

# For each environment, save revision information
conda list -n base --revisions > check_revisions_base.txt
...

YML file

conda document に記載があるように、現在の環境を.ymlファイルとして出力することができる。

# For each environment, save YML files for future rebuild of the environment
conda env export -n base  > environment_base.yml

このようにして出力したり、自ら編集したりした.ymlファイルは、将来的に環境をrebuildするのに使用できる。

Explicit specification file

同一の環境を同じプラットフォーム上に構築するための情報をexportすることができるようだ。

これで、何か起こった際に一から再構築するための準備を一応できたと考え、condaのロールバックを実施することにした。

2. 以前のrevisionにロールバック

現在起こっている依存性の問題と、そのせいでcondaがアップデートできなくなっていることを解消するために、問題が起きていなかった時期の状態までロールバックして過去の環境をレストアし、そこから再度最新のcondaにアップデートすることを考えた。ロールバックすることで、それまでに導入したパッケージはbase環境から失われてしまうが、その前にbase環境をコピーして新しい環境を作っておくことで、一応現状の環境が使いたくなった時のバックアップを確保した上でbase環境に手を入れることができる。

実際の実行では、HOME下のminiconda3ではなく別のディレクトリに環境をクローンするために-pを使用した。

conda create -p /path/to/project/dir/env/base_2 --clone base

これでbaseをいじって万が一変なことをしてしまったとしても、base_2を使って以前の解析ができる。

準備ができたところで、上述のrevisionの情報と、そこで導入されているパッケージ、不具合がみられ出した時期を照合して、どこまでロールバックしてやれば良いかにあたりをつけた。その上で、以下の要領でレストアを実施した。

# rollback to the previous revision
conda install -n base --revision={int}

不具合が生じた時にロールバックして環境をレストアすることについては、調べていてあまり第一の選択肢として上がっていなかったような気がする。以下のサイトでコメントしている人がいた。

上の解決方法のいくつかは実際に実施したが、自分が経験ではうまくいかず、ロールバックして綺麗にする方法がうまく行った。ロールバック実行後、conda updateを実施できる状態になり、unexpected errorでエラーレポートを吐いて先に進めない状態から脱することができた。conda -Vにより確認すると、ロールバック直後には、指定したrevisionのところに記載されていたconda versionまで巻き戻っていた。

ここで生じた問題点

そこからconda update conda -n base -c conda-forgeを実行すると、revisionデータで見た時の、ロールバックした状態の一つ上のバージョンまでupdateされた。期待していたこととしては、現在一番最新のconda(実施時には23.11.0)までアップデートされると思ったが、そのずいぶん手前までしかアップデートされなかった。

3. condaのversion up

上述のように、ロールバックして依存問題のない環境まで巻き戻ることはできたのだが、別の問題として、condaのバージョンを最新のものまでアップデートすることができない状態が生じた。それ以外のパッケージはアップデートすることができた。

# 抜粋
==> WARNING: A newer version of conda exists. <==
current version: 22.11.1
latest version: 23.11.0

Please update conda by running

    $ conda update -n base -c conda-forge conda

Or to minimize the number of packages updated during conda update use

    conda install conda=23.11.0


# All requested packages already installed.

メッセージ通りにconda updateを実施しても、同じメッセージが出力されるだけでどうしても23.11にアップデートされなかった。どうしてこのような状態になっているのかはよく分からなかった。解決方法としては、最新のcondaのインストーラーをダウンロードしてきて再インストールすることだと思われたが、同じくメッセージに書かれているバージョン指定したインストールを実施してみることにした。

conda install conda=23.10

condaのバージョンは最新のものや戻ったrevisionでのバージョンに近いものなどいくつかを試してみたが、時間がかかりすぎるものもあり、結果的に23.10に指定した時にうまく行った。これによって、v23.10.0までjump upできた。

続けて、ここから最新のversionにアップデートできるのかを試行した。

conda update conda -n base -c conda-forge

今度はうまく行って、最新の23.11.0にcondaをアップデートすることができた。

これで、base環境に生じていた依存性の不具合を解消し、condaを最新のバージョンまでjump upさせることができたと考えられる。続けて、condaにより解析用の環境を別途再構築することにした。

4. .condarcの設定

conda createの際に便利なように、create_default_packages.condarcに設定し、新しい環境を作る際にデフォルトでインストールするパッケージを記載しておくことにした。

# Set create_default_packages on .condarc
# Frequently used python packages:

conda config --add create_default_packages ipython
conda config --add create_default_packages jupyterlab
conda config --add create_default_packages pandas
conda config --add create_default_packages numpy
conda config --add create_default_packages scipy

5. 解析環境の構築

(base)に変わる解析環境として、(ana)を構築する。

  • Status of Python versions

    Status key
    feature:
    new features, bugfixes, and security fixes are accepted.

    prerelease:
    feature fixes, bugfixes, and security fixes are accepted for the upcoming feature release.

    bugfix:
    bugfixes and security fixes are accepted, new binaries are still released. (Also called maintenance mode or stable release)

    security:
    only security fixes are accepted and no more binaries are released, but new source-only versions can be released

    end-of-life:
    release cycle is frozen; no further changes can be pushed to it.

上記のpython.orgで確認すると、現在のstable最新版は3.12ということで、python=3.12にして環境構築することにした。これまで3.9でずっといたので、だいぶ上げることになった。

# Generate ana environment
# For this environment, python 3.12 was specified.
conda create -p /path/to/my/private/miniconda3/envs/ana python=3.12

継続して、解析時に頻度高く使用しているものとして、以下のパッケージを導入することにした。

  • seaborn
  • matplotlib
  • scikit-learn
  • openpyxl
  • xlrd

markdown関係に必要なもの

  • nbconvert: Convert Notebooks to other formats

    Using nbconvert enables:
    • presentation of information in familiar formats, such as PDF.

    • publishing of research using LaTeX and opens the door for embedding notebooks in papers.

    • collaboration with others who may not use the notebook in their work.

    • sharing contents with many people via the web using HTML.

documentationのインストールチュートリアルに従い、必要なパッケージ等の導入を実施した。

# nbconvertとpandocの導入
conda install nbconvert pandoc

# TexLiveのインストール
# 以下、TeXLiveサイトの通り。
# サイズが大きいので、余裕のある場所を選んで指定した。

# documentationを見るに、htmlへの変換はTeXなしでも可能だが、pdfへはTex導入が必要のようだ。
# TexLiveに必要なものがまとめられているようだが、condaで検索したところtexlive-coreしか
# インストールすることができないようだったので、本家サイトにそってインストールした。
# 
# Make install location dir
cd /path/to/install/applications
mkdir Tex
mkdir Tex/personal
# Download installer
cd /path/to/installer/downloaded/dir
wget https://mirror.ctan.org/systems/texlive/tlnet/install-tl-unx.tar.gz 
zcat < install-tl-unx.tar.gz | tar xf -
cd install-tl-*
# Execute installation
perl ./install-tl --texdir=/path/to/install/applications/Tex --texuserdir=/path/to/install/applications/Tex/personal

# Add path 
export PATH="/path/to/install/application/Tex/bin/{architecture}:$PATH"
export MANPATH="/path/to/install/application/Tex/texmf-dist/doc/man:$MANPATH"
export INFOPATH="/path/to/install/application/Tex/texmf-dist/doc/info:$INFOPATH"

終わりに

condaの環境に問題が生じる要因としては、環境に新しいパッケージが野放図に追加されていくことにより依存性の問題が生じて、アップデート等含めて様々な操作の障害になっていくことが考えられる。特に、base環境は他の環境とは異なり削除することが難しいため、baseは実質的には汚さずに置いておき、実際の解析環境や、特殊な用途のパッケージを導入する環境を個別に作成する方が良いのかもしれない。問題が起きたときに個別の環境をremoveすることで対応することができる。

依存性の問題を生じさせないためには、コンフリクトを生じさせないように用途に応じて個別に環境構築していくことが良いように思われるが、ホーム下にcondaを置いてしまっている場合は、たくさん環境を作っているとdisk usageを圧迫してしまう可能性がある。プロジェクトごとの環境はプロジェクトディレクトリに格納したり、余裕がある場所に環境格納用のディレクトリを指定し、conda createの際に-pでpath指定で構築するというのが良いかもしれない。