【Bash】Windows Subsystem for Linux【WSL】6
■ このスレッドは過去ログ倉庫に格納されています
WSL2アーキテクチャ
https://www.atmarkit.co.jp/ait/articles/1906/14/news019.html
WSL 2では、仮想マシン環境が起動し、bashがコマンドを受け付けるまで2秒程度という速度で起動できる。
このため、コマンドプロンプトなどからwsl.exeなどを使ってbashコマンドを処理する時間は、
現在のWSL 1とほとんど変わらない。また、本物のLinux実行環境であるため、
これまで正しく動作できなかったアプリケーション、例えばコンテナシステム（Dockerなど）や
ユーザーファイルシステム（FUSEなど）も動作させることができる。その上で、現在のWSL 1と同等の機能と使い勝手を実現するという。
WSL 2はWSL 1を置き換えずに併存する
WSL 2が登場したからといって、WSL 1は廃止になるわけではなく、引き続き利用可能である。
ファイル共有プロトコル「9P」でWSL 1との互換性を確保
このように、WSL 2とWin32環境の間のファイル共有は、どちらも9Pを使うことになる。
また、WSLからWin32プログラムを起動する「Win32相互運用性」では、最初にWSL側で、
実行ファイルを判別する必要がある。具体的には、実行ファイル先頭のマジックナンバー
（Win32ではMZ）を見て、LinuxのELF64か、Win32の実行ファイルなのかを判断する。
【Bash】Windows Subsystem for Linux【WSL】5
https://mao.5ch.net/test/read.cgi/linux/1553100855/ WSL1の時に9P通さずにWindows側から見えてるファイルをいじるとLinux側と齟齬が生じて支障するって話を理解できず「NTFSのMFTやファイルが壊れないのだからLinux側で問題が発生する訳がない」とか言い張っていた頭弱い子じゃないかなそいつ pageantとの連携に何使ってる？
weasel-pageantを使っていたんだが、どうやらたまにおかしくなって
バックグラウンドでCPUを食いまくる減少があるようだ。
WSLのバックグラウンドプロセスの仕組みに問題があるのかもしれないが weasel-pageant関係なかった。使わずにいてしばらく発生しないからそうだと思っていたんだが
ふいにbashがフリーズして、そしたらCPU食いまくる状態になった。
しかも強制終了も受け付けない。なんだこりゃ wsl1は、特定のプロセスが暴走したあとkill -9もタスクマネージャからも殺せなくなることがあるね
wslサービス自体を殺すしかない。暴走しないままゾンビ化したみたいになった場合も同様。
wsl2はinitの暴走がたまにあるけど、こちらはkill -9で殺せてる。
原初のinitは暴走したことないので、wsl2を呼び出すツールによるのかもしれない。 >>106
殺せればそれでいいんだけど、どうやっても殺せない。
bashは殺せないし、Lxss マネージャーだっけ、あれも殺せない。
現状再起動しか対応策が見つからない。 ふとbashが暴走するなら、bashを使わなければいいじゃないと思いついた。
コマンドプロンプトからwsl --exec shでshが起動できる。
/initの下はshが来てる。そこからbashを起動してみた。zshを起動することも可能だろう。
ちょっとコレで試してみるか chshって使えるのか。コマンドプロンプトからだと忘れそうなので、
shに変更・・・したらなんかエラー出るのでzshに変更。
zshの設定はしてないので、そこからbashに切り替える。
またbashが暴走するかもしれないが、この状態ならWSLの世界でbashを殺せるかもしれないしね。
もしそれがだめならzshの設定をしてみる。
なんとなく今度はzshが暴走する気がしてるがｗ POSIX準拠じゃないけどfishオススメ。
zshから乗り換えた。 wsl1暴走したことないから分からないけど、terminateオプションでの再起動も無意味なん？ >>111
試してないけど無理だと思う。
なにせ管理者権限で起動したProcess Explorerでさえ殺せないから
暴走状態といっても何故かCPU使用率12%ぐらいで
なんか最近ファンが高速回転しやすいなって思って気づいた
いつからなのか？前はなかった気がするから1903からなのか？
前はどうやっても消せないゾンビプロセスが残るという問題があったが
1903でそれが修正されたのは知ってるんだが、関連のバグなんじゃないのかな？
WSLがおかしくなって、関連したbashが暴走しだすのか、単にWSL環境下でbashが暴走してるだけなのか、
前者ならzshにした所でbashではなくzshが暴走するだけだろうけど今の所問題は発生していない >>103 に関連して。
wslttyをChocolateyでバージョンアップしたあとは、スタートメニューから検索して
"WSL Generate Shortcuts" を実行しないと、更新が反映されないことに自分はしばらく気づかなかった。 >>112
CPU使用率が12%ってことは8コアか4C8TのCPUで1スレッドだけ暴走してるかと
100%÷8=12.5% >>114
それもそうだｗ
間にzsh挟んでから暴走しなくなった。
と油断した所で、weasel-pagentを使ってみたら
初めてこいつが暴走した。暴走したときの挙動は同じ。
ただ今回はkillすることができた
やっぱり本当の原因はこいつなんだろうか？
それともたまたま全く違う事が起きただけなんだろうか？ 暴走したプロセスにgdbでアタッチとか出来ないかな？ また暴走した。プロセスツリーはこんな感じでbashがフリーズ
init -> zsh -> bash
ただし、フリーズした状態ではCPU食わず、bashを殺すことも出来た。
zshを殺そうとしたら、死なずにzshが暴走し始めた。
根本解決はしてないけど、静かに生き残るなら問題ないわｗ
フリーズしたらそのまま放置する >>116
Attaching to process 16018
warning: process 16018 is a zombie - the process has already terminated
ptrace: そのようなプロセスはありません.
こうなった。言ってなかったかもしれないけど暴走したプロセスはゾンビ状態になってる。
あと今回 weasel-pagent は起動してないので関係ないことが判明した。 なんかおかしい時は真っ先にアンチウイルスを疑うことにしている Windows 10だったらDefenderだけでいい。余計なもん入れるな。 >>122
除外リストに入れればパフォーマンスは大丈夫 除外リストに入れても、チェックしたあとに結果を無視するだけなので、だめなのよ
githubで中の人が、セキュリティは別チームだけどなんとかしたいといってから
2年以上たったけど、WSL2でたからこのまま放置されるでしょ Windows 10 Receives Significant WSL2 Improvements
https://winaero.com/blog/windows-10-receives-significant-wsl2-improvements/
Yesterday Microsoft accidentally released a new 'canary' build of Windows 10 to all Insider rings. Windows 10 Build 18947 adds the following improvements to WSL 2:
･new kernel 4.19.55 with no cap at 8 cores/threads, support for docker-compose, kubernetes...and more.
･umask 0022 as default
･way better memory management, now its an authentic "balloon" with reduced memory footprint. umaskの修正とlocalhostでのアクセスは確認できたけど、
メモリ管理の改善は違いがわからない
localhostでのアクセスとumask直しただけで、一般公開してくれていい出来 localhostが使えるようになったってことはWSL1を使い続ける理由がなくなるのか？ Hyper-Vって、ゲストOSとホストOSのクリップボード連携とかがWindows同士でしかできなかったんで、自分はすぐ使うのをやめた。
あれはWindowsを動かすためのVMであって、たまたまLinuxもちょっと動くというだけだろう。 ubuntuはhyperVにもまともに対応しているが hyperv上のでubuntuは、virtualboxでいうtoolboxが存在しないので、
GUIでの描画は遅いし、windowは任意のサイズに変更できなかったりで
使い勝手は悪い。xrdp経由だから、クリップボード共有はできる。
disk passthroughなら、I/Oは実機の95%以上の性能をだせるので、
ここは他のVMと変わらない。 wsl2のlocalhostでのアクセスは失敗するケースが結構あって
結局スクリプトで対応してる >>136
しかもWin→WSLのみでWSL→WinにはアクセスできないからX11は結局localhost以外からの接続を許可する必要があるらしいね
ところでこのスレにはPengwin使ってる人はいないの？
1150円も出して買った情弱なんだけどFcitxが使えてる人がいるのか知りたい WSL1のUbuntuでGNOME3入れて日本語入力はfcitxでやってるけどできるよ。
XサーバはVcXsrvとX410両方で問題なし。 >>133
> Hyper-Vって、ゲストOSとホストOSのクリップボード連携とかがWindows同士でしかできなかったんで、
その話がWSLとなんか関係あんのか？ >135
存在しないんじゃなくて、普通のドライバと同じように
HyperVのドライバもLinuxカーネルに付属してるから
別途入れる必要はないだけ。virtualboxとは違うんだよ
Hyper-V配下のCentOSの仮想マシンに統合サービスを入れる
https://blog.pcdiary.mydns.jp/pc/linux/post-518/
> CentOS7には標準で統合サービスがインストールされている為、別途インストールする必要はないが Hyper-V 統合サービス
https://docs.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/reference/integration-services
統合サービス (多くの場合、統合コンポーネントと呼ばれます) は、
仮想マシンから Hyper-V ホストに通信できるようにするサービスです。
クイック リファレンス
名前 Windows サービス名 Linux デーモン名 説明 無効にした場合に VM に与える影響 >>139-141
その話がWSLとなんか関係あんのか？ >>139
> その話がWSLとなんか関係あんのか？
俺はとても親切だから、何が関係するのか、愚かなお前に教えてやろう。
その2レス前から読み返せ。そしてもし理解できたら俺に謝れ。 謝罪がないということは、理解できなかったということだな。
不思議だなあ。ID:/rx8wPTw は >>143 で、何が関係するのかについて同じことを説明しているのになあ（棒読み）。 https://github.com/microsoft/linux-vm-tools
現状はゲストにこれ入れて拡張セッションモードで動かせばクリップボードの共有はできるようになる
窓のライブリサイズはXRDP側の対応次第みたいねhttps://github.com/neutrinolabs/xrdp/issues/448
ID:/rx8wPTwは例の人だろうけど知らない話題にいちいち口出さなければいいのにね さて、嫌味もこのぐらいにしておこうか。
この機会に ID:/rx8wPTw に言っときたいんだけど、あんたこのスレに常駐してMSのネガティブ情報の打ち消しをやってるだろう？
そのこと自体は悪いことじゃないし、むしろみんなにメリットがあるだろう。あんたMSの技術に詳しいからな。
しかし、あんたは相手のレスをちゃんと読まずに、単なるクソリプになってることがしばしばある。
それでも相手が反論してこないのは、あんたの主張が勝ったんじゃなくて、単に相手が関わるのをめんどくさがってるだけだ。
つうか俺もあんたのクソリプを食らったのはこれが初めてじゃないんだわ。めんどくさかったから反論しなかったけどな。
あんたの書き込む技術情報には価値があると思うんで、今後はどうかその点に留意してくれ。 >>147
お前何一人で空回りしてるの？
相手のレスをちゃんと読んでないのお前じゃんｗ たまたまわかりやすいページが出てきたから書いておくか
https://tech.akat.info/?p=233
> Win 2012 R2とlinuxのHyper-V統合サービスについて
> 新しいディストリビューションの登場に応じて、組み込み Linux 統合サービスを追加している
> What’s New in Hyper-V for Windows Server 2012 R2
> Debian Wheezy本体に含まれるLinux Kernel 3.2.0にはHyper-Vのモジュールが
> デフォルトで組み込まれていて追加の設定なしで使うことができる
virtualboxでいうtoolbox相当のものは
Linuxカーネルに組み込まれている https://www.atmarkit.co.jp/ait/articles/1808/30/news024_2.html
> 「拡張セッションモード」は、仮想マシンとの内部的な通信のための仮想マシンバス（VMBus）を通じ、
> リモートデスクトッププロトコル（RDP）でWindows仮想マシンのデスクトップに
> 接続する機能です。リモートデスクトップ接続で利用可能なデバイスのリダイレクト機能（
> プリンタ、ドライブ、PnPデバイス、RemoteFX USBデバイス）やクリップボード共有といった機能を、
> 「仮想マシン接続」ウィンドウで利用できるという利点があります。
> 「拡張セッションモード」は、仮想マシンのゲストOSがリモートデスクトップ接続のサーバ機能をサポートする
>Windows 10とWindows Serverで利用できますが、Windows 10 バージョン1803からは
>Linuxゲストに対しても利用できるようになりました（画面5）。
>Linuxゲストに対しても利用できるようになりました（画面5）。 hyper-vの拡張セッションモードはxrdpに依存した遅すぎる描画だけでも改善してほしいけど、
desktop環境はターゲットじゃないだろうから厳しいか
拡張セッションモードがゴミじゃなければ、hyper-v使い続けてたわ >>148
なんだ単なる異常者だったか。たぶん発達系だな。
てっきり早とちりしがちの善意の人かと誤解してたよ。情けをかけたのは無意味だったわ。アホくさ。
以後完全にスルーするわ。 >>151
https://forest.watch.impress.co.jp/docs/serial/win10tips/1152934.html
> 「Hyper-V」では、仮想マシンへの接続に、“仮想マシン接続”と“拡張セッション”の2種類を選択できます。
"仮想マシン接続"を使えばいいだけでは？
> “拡張セッション”はリモートデスクトップの技術をつかった接続方法で、仮想マシンのリソースを扱えるようになるのが特徴です。
>接続時にオプションの［ローカルソース］で、ホストPCのドライブや接続したUSBメモリを仮想マシンにマウントすることなどができます。
>ホストPCとデータのやり取りが必要な場合は、この方法が簡単です。
こういうのはVirtualBoxのtoolboxにはない高度な機能 >>153
どういう理屈で、拡張セッションでのxrdpの描画が遅すぎるというひとに、
それよりも遥かに遅い仮想マシン接続を勧めるのでしょうか？
共有フォルダの自動マウント程度はvmware/virtualboxの初期バージョンから
RDP使わずに実装されてましたよ こういうのもあるみたいね
https://www.atmarkit.co.jp/ait/articles/1810/09/news009.html
> RemoteFX vGPUは、リモートデスクトップ仮想化ホストの役割を実行する
> Hyper-Vホストに搭載された物理GPUを仮想化して、複数の仮想デスクトップに
> 「RemoteFX 3Dビデオアダプター」デバイスを提供し、リモートデスクトップセッション内でGPU機能を利用可能にします。
こｒからはこっちの技術がベースになるのかな？
Hyper-V仮想マシンでDDAを利用したGPUパススルー
https://nashippe.blog/hv/gpu-passthrough/
> Windows Server 2016における新機能の一つに、Hyper-V仮想マシンにおける
> Discrete Device Assignment（DDA）の対応があります。DDAの実装により、
> Hyper-V上の仮想マシンでPCIeデバイスを利用できるようになります。
https://docs.microsoft.com/ja-jp/windows-server/remote/remote-desktop-services/rds-graphics-virtualization
> ゲスト OS のサポート Windows Server 2012 R2 Windows Server 2016 Windows 10 Linux
ちゃんとLinuxも入ってるね。 >>154
仮想マシン接続の方が速いでしょ？
拡張セッションは便利機能。
> 共有フォルダの自動マウント程度はvmware/virtualboxの初期バージョンから
それリモートじゃないし。
リモートにあるVMに接続して、手元のDVDドライブから読み込むとかできません。 >>156
仮想マシン接続のほうが遅いですよ
あと、リモートにあるVMに接続して云々についてですが、
RDP一般であれば正しいですが、hyperv上でのxrdp/拡張セッションでの接続は、
ホストPCからしか接続できないです。
あとRemoteFX vGPUは今後サポートされる見込みがないですよ > あとRemoteFX vGPUは今後サポートされる見込みがないですよ
もっと優れた代替技術に変わるようだね。 もうそろそろ、Virtualboxのtoolbox相当が存在しないなんていう嘘の話は消えた？
まあ、あるという前提での話になっちゃってるからね。 マイクロソフト太っ腹やなｗ
Hyper-VにインストールしたUbuntu 18.04の画面解像度を変更する
https://gazee.net/develop/hyper-v-ubuntu-screen-resolution/
結論から言うと、Microsoftが公開しているlinux-vm-toolsをインストールすることで画面解像度を変更することができるようになります。
このlinux-vm-toolsは、その他にもクリップボードの共有機能もあり、インストールしておくと非常に便利です。 Hyper-Vって、ゲストOSとホストOSのクリップボード連携とかがWindows同士でしかできなかったんで、
自分はすぐ使うのをやめたとか言ってる人がいたけど、
本当はできるわけだよね。そいつは馬鹿だなぁと思った。 vhdxってNTFS圧縮するのはダメなのね
WSL2が起動しなくなって何事かと思った WSL2のlocalhost接続がこけた場合のlocalhost接続だけの復旧方法がわからない
vNetworkと別口だとは思わなかったわ
docker for WSL2以外では、使えなくても問題なさそうなところが微妙 WSL使ってる奴は池沼だろ
ドザーなら潔くpowershell(笑)とchocolatey(爆笑)で乗り切ってみろよ雑魚wwwwww Apple信者ってなんでMSに敵意持ってるの？
潰れそうだったAppleに資金提供してくれたから感謝する、なら分かるけど wsl2で構築したlinux環境をまるごとdropbox等のネットワーク上に
上げて、違うPCから同じlinux環境で作業することって出来ますか？ 曖昧な質問だけど、
・export/importの話ならできる
・ネットワーク上にwslのdistributionを置いたまま使うという話なら無理 169でも言ってるけど、export、importpで良いやろ
別端末に同じ環境って意味合いなら >>138
ありがとう、Pengwin以外だと問題ないみたいね
ってpengwin-setupのバグみたいだからそりゃそうだけど
profile.dの生成がおかしくてdbusとfcitxの起動がうまく行ってなかった
Debianでtask-japanese-desktopを入れたらuim-mozcが入ったけどこのままibusやfcitx入れちゃっても大丈夫なんだろうか conemuからwslやるとzsh重いからfishにしてみたけどタブ補完の動きがおかしい……
結局bashに帰ってきちゃった docker for wsl2は、wsl2の環境作ってあれば、あまり価値なかった それコンテナ技術の意味合いが分かってないだけじゃないのか？ WSLとDockerの環境は全然別物。使い方も違う。
本当にわかってないだろw docker for wsl2は、wsl2上にdocker-cliインストールしてくれるのと
クリックで動作・停止できるくらいしか機能ないから、
docker-cliインストールして使ってればいい >>176
当たり前じゃね？
Docker社が作ったのはDockerであって、
Docker DesktopやDocker for Windowsは
Linuxで動くDockerをWindowsに移植したようなもんだろ？
今までWindows版のRubyを使っていたが
WSLでWindows版Rubyはいらなくなった！って言ってるのと同じで
別にRubyがいらなくなったわけじゃないでしょ？
WindowsがLinuxを内包したから、Windows版が
要らなくなったという話の一部でしか無いよ せめて、docker desktop for win使ってから書けばいいのに わかってないのは>>177>>179>>181のほうだが
ID:wgwFcBqKのほうがクソレスだと思う >>175
conemuは機能的にはいいけどハードスペックでどうにかなる類いの重さじゃないし
UIもごちゃごちゃして使いにくいな 間違えた
>>184
だからお前よりもわかってるってｗ Debianのインストールイメージがbusterになったみたいだしまたリセットすっかな core-i3(6gen, SSD)のマシンが余ったからinsiderデビューしてみた。
WSL2にして、npm installとかI/Oまわりは実機の7割くらいの速度に改善されてよかったんだけど、
I/O以外で遅くなったりしているから、compileにかかる時間が読みづらかった。
gitやvirtual envの情報をpromptに表示させてたけど、directory移動するたびに少しだけ待たされる。
WSL1や、12年前のlaptop(core2duo, HDD)上のlinuxですら瞬時に表示されるというのに。
とりあえず非同期処理に書き直して対応。
単体としては満足だったけど、VMとの排他利用だと悩む。 >>190
でも、それをいったらMacってなんであんなに遅いんだろうね
WSLなみに遅いよ。 >>192
嘘だと思うなら、こんな感じのコード実行してみ
#!/bin/sh
i=0
while [ $i -lt 1000 ]; do
date > /dev/null
i=$((i+1))
done
俺の環境でLinuxだったら1秒だけど、Macだと3秒かかる。 その手のだとOS云々よりもMeltdown対策がどうなってるかで倍ぐらい変わりそうだな >>193
それが本当だとしてもそのコードが遅いことにどういう意味があるの？ うん。Macのカーネルはフォークが遅いんだと思ってる。
Unixとしては実装が片手落ち。取りあえず動くけど最適化されてない dateが遅いだけとか言われそうだから改良してみた。
ともにbashで実行。バージョンは少し違ってMacは5.0.7で、Linuxは5.0.3
MacはMacBook ProでLinuxは同じマシンでしかも仮想マシン（VirtualBox）で実行
#!/bin/bash
i=0
while [ $i -lt 10000 ]; do
( : )
i=$((i+1))
done
dateコマンドを呼び出していない。サブシェルを使ってるから実質フォークのみが行われている。
Linuxだと3.5秒だが、Macだと9秒かかる。とても遅い。 macosのforkが遅いのは以前からさんざんベンチ付きでいわれてたことだし、
windowsにfork相当がないことやwsl1のfork実装がmacosよりも遅いってのも
このスレでも既知のことでしょうに。
>>191は何を言いたかったのかわからない。
あなたが遅いと言ってるのはmacosのforkが遅いってことですよね？
理由は、自身が>>196で書いてる通り、macosのfork実装が悪いんでしょう。
wsl2の話にどうつながるんでしょうか？ macosのforkが遅い,windowsにfork相当がないのはGUIソフトではforkは使わない
からなのか？
実はLinuxでもGUIソフトではforkは(ほとんど？)使っていないとか >>198
> wsl2の話にどうつながるんでしょうか？
WSL2では内部で仮想マシンを使ってるから、
Macで動かしたVirtualBox上のLinux相当のパフォーマンスになるよ
高速だね！ >>174だけどfcitx-mozcは動いたもののibus-mozcが動かない
そもそもibus-daemonが起動しなくてググってみたけど有力な情報がなくて断念 ■ このスレッドは過去ログ倉庫に格納されています
