WSL2でDNS解決がうまくいかない問題と解決方法

WSL2でDNS解決がうまくいかない問題と解決方法

こんにちは!

Windows Subsystem for Linux (WSL2)は、Windows上でLinux環境を利用できる素晴らしい機能ですが、中にはDNS解決に関する問題が発生することがあります。この記事では、その症状と効果的な解決方法を紹介します。

検証環境

この記事で紹介する方法は、以下のバージョンで検証しています

WSL バージョン: 2.4.13.0
カーネル バージョン: 5.15.167.4-1
WSLg バージョン: 1.0.65
MSRDC バージョン: 1.2.5716
Direct3D バージョン: 1.611.1-81528511
DXCore バージョン: 10.0.26100.1-240331-1435.ge-release
Windows バージョン: 10.0.22631.3880

症状

以下のようなエラーメッセージが表示される場合、WSL2でのDNS解決に問題が発生している可能性が高いです:

  • コマンドラインから接続時: Could not resolve hostname ...
  • Pythonコードから接続時: [Errno -2] Name or service not known

これらのエラーは、WSL2内でDNSサーバーの設定が正しく行われていないことを示しています。

原因

WSL2は起動時に自動的に /etc/resolv.conf ファイルを生成し、Windows側のDNS設定を使用しようとします。しかし、この自動生成されるDNS設定が正しく機能しないケースがあります。上記のバージョン情報にあるように、2025年3月時点の最新WSL2(バージョン2.4.13.0)でもこの問題は完全には解決されていません。

解決方法

以下の3ステップで問題を解決できます

STEP1: WSL2が自動生成するDNS設定を無効化

WSL bashで以下のワンライナーを実行して、resolv.confが自動生成されるのを防ぎます。

注意:既存のwsl.conf があるばあいはvim等で編集してください。

sudo sh -c 'cat > /etc/wsl.conf << EOF
[network]
generateResolvConf = false
EOF'

このコマンドは、WSL2の設定ファイル /etc/wsl.conf を作成し、DNS設定の自動生成を無効にします。

STEP2: Windows側でWSLを再起動

Windows PowerShellまたはコマンドプロンプトで以下のコマンドを実行し、WSLを完全に再起動します

wsl --shutdown

STEP3: DNSサーバーを手動で設定

WSLを再度起動し、シェルで以下のコマンドを実行して、GoogleのパブリックDNSサーバーを手動で設定します

sudo sh -c 'cat > /etc/resolv.conf << EOF
nameserver 8.8.8.8
EOF'

これにより、GoogleのDNSサーバー(8.8.8.8と8.8.4.4)を使用するように設定されます。

確認方法

設定が正しく適用されたかを確認するには、以下のコマンドを実行してみてください

ping google.com

または、以下のPythonコードでの接続テスト

import socket
socket.gethostbyname('google.com')

WSLのカーネルバージョンを確認するには、以下のコマンドが使用できます

# カーネルバージョンの簡易表示
uname -r

# カーネルバージョンの詳細表示
cat /proc/version

# システム情報全体の確認(systemdが利用可能な場合)
hostnamectl

また、WindowsコマンドプロンプトまたはPowerShellからWSLのバージョン情報を確認するには

wsl --version

これらが正常に動作すれば、DNS解決の問題は解決されています。

注意点

  • この設定はWSLを再起動するたびにリセットされる可能性があります。その場合は、STEP3を再度実行する必要があります。
  • WSLのバージョンによっては動作が異なる場合があります。最新の情報については、Microsoftの公式ドキュメントを参照することをお勧めします。

まとめ

WSL2でのDNS解決問題は、自動生成されるDNS設定を無効化し、手動でDNSサーバーを設定することで解決できます。この方法は、最新のWSL2バージョンでも有効です。

Read more

発話音声からリアルなリップシンクを生成する技術 第1回:音素とwav2vec

発話音声からリアルなリップシンクを生成する技術 第1回:音素とwav2vec

こんにちは! 今日は当社のMotionVox でも実際に使っている「リップシンク」技術について総合的に解説してみたいとおもいます。 音声に合わせて自然な口の動きを生成するリップシンク技術は、AIアバターや3Dアニメーション制作においても重要な技術です。 本記事では、最新のディープラーニング技術を活用したリップシンク学習の基礎から実装まで、技術的な観点から詳しく解説します。 1. リップシンク学習の基礎概念 1.1 問題設定 リップシンク学習とは、音声データから対応する口の動きを予測する回帰問題ととらえることができます f: 音声特徴量(t) → 口の動きパラメータ(t) この問題のコアは 音韻(音の特徴)と視素(視覚的な口の形)の対応関係を学習する ことにあります。 1.2 音韻-視素マッピングの複雑性 ただし! 人間の発話における音と口の形の関係は、単純な1対1マッピングではないんです。 同じ音でも文脈で変化 「あ」の発音でも: - 「か」の後の「あ」→ 口がやや狭めから開く - 「ん」の後の「あ」→ 口が閉じた状態から大きく開く 調音結合

By Qualiteg 研究部, Qualiteg コンサルティング
LLM推論基盤プロビジョニング講座 第3回 使用モデルの推論時消費メモリ見積もり

LLM推論基盤プロビジョニング講座 第3回 使用モデルの推論時消費メモリ見積もり

こんにちは!前回はLLMサービスへのリクエスト数見積もりについて解説しました。今回は7ステッププロセスの3番目、「使用モデルの推論時消費メモリ見積もり」について詳しく掘り下げていきます。 GPUメモリがリクエスト処理能力を決定する LLMサービス構築において、GPUが同時に処理できるリクエスト数はGPUメモリの消費量によって制約されます。 つまり、利用可能なGPUメモリがどれだけあるかによって、同時に何件のリクエストを処理できるかがほぼ決まります。 では、その具体例として、Llama3 8B(80億パラメータ)モデルをNVIDIA RTX A5000(24GB)にロードするケースを考えてみましょう。 このGPUには24GBのGPUメモリがありますが、すべてをリクエスト処理に使えるわけではありません。最初にモデル自体が一定量のメモリを消費し、残りの領域で実際のリクエスト処理を行います。 GPUメモリ消費の二大要素 GPUの消費メモリ量は主に以下の2つの要素によって決まります 1. モデルのフットプリント LLMをGPUに読み込んだときに最初に消費されるメモリ

By Qualiteg コンサルティング
システムとcondaのC++標準ライブラリ(libstdc++)のバージョン違い問題による事象と対処法解説

システムとcondaのC++標準ライブラリ(libstdc++)のバージョン違い問題による事象と対処法解説

こんにちは! 先日、dlibをつかったPythonアプリケーション(conda環境で動作する)作っていたところ、以下のようなエラーに遭遇しました。 ImportError: /home/mlu/anaconda3/envs/example_env/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /home/mlu/anaconda3/envs/example_env/lib/python3.10/site-packages/_dlib_pybind11.cpython-310-x86_64-linux-gnu.so) 「dlib_pybind11モジュールがGLIBCXX_3.4.32を要求してるけど、みつからない!」という感じのエラーですね。

By Qualiteg プロダクト開発部
LLM推論基盤プロビジョニング講座 第2回 LLMサービスのリクエスト数を見積もる

LLM推論基盤プロビジョニング講座 第2回 LLMサービスのリクエスト数を見積もる

こんにちは! 今回はLLM推論基盤プロビジョニング講座 第2回です! STEP2 LLMサービスへのリクエスト数見積もり それでは、早速、LLM推論基盤プロビジョニングの第2ステップである「リクエスト数見積もり」の重要性と方法を解説いたします。 LLMサービスを構築する際に必要となるGPUノード数を適切に見積もるためには、まずサービスに対して想定されるリクエスト数を正確に予測する必要があります。 リクエスト数見積もりの基本的な考え方 LLMサービスへの想定リクエスト数から必要なGPUノード数を算出するプロセスは、サービス設計において非常に重要です。過小評価すればサービス品質が低下し、過大評価すれば無駄なコストが発生します。このバランスを適切に取るための基礎となるのがリクエスト数の見積もりです。 想定リクエスト数の諸元 リクエスト数を見積もるための5つの重要な要素(諸元)をみてみましょう。 1. DAU(Daily Active Users): 1日あたりの実際にサービスを利用するユーザー数です。これはサービスの規模を示す最も基本的な指標となります。 2. 1日

By Qualiteg コンサルティング