【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/ >>99 お前さ、イメージファイルとして一つのファイルになっているものは触らないのにさ、 その中身が展開されている、ただし直接触ることを想定してないし、 だからこそ分かりづらい場所に格納されてるもの、をわざわざ探し出して触るわけ? どちらも想定してない使い方なんだから、壊れても当たり前だし、 どちらも9Pプロトコルで安全に触れるようになったじゃん しかも時系列的には、WSL1で安全に触れるようになった→その応用でWSL2も対応 という流れなんだが 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が暴走する気がしてるがw 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 それもそうだw 間にzsh挟んでから暴走しなくなった。 と油断した所で、weasel-pagentを使ってみたら 初めてこいつが暴走した。暴走したときの挙動は同じ。 ただ今回はkillすることができた やっぱり本当の原因はこいつなんだろうか? それともたまたま全く違う事が起きただけなんだろうか? 暴走したプロセスにgdbでアタッチとか出来ないかな? また暴走した。プロセスツリーはこんな感じでbashがフリーズ init -> zsh -> bash ただし、フリーズした状態ではCPU食わず、bashを殺すことも出来た。 zshを殺そうとしたら、死なずにzshが暴走し始めた。 根本解決はしてないけど、静かに生き残るなら問題ないわw フリーズしたらそのまま放置する >>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 お前何一人で空回りしてるの? 相手のレスをちゃんと読んでないのお前じゃんw たまたまわかりやすいページが出てきたから書いておくか 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機能を利用可能にします。 こrからはこっちの技術がベースになるのかな? 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相当が存在しないなんていう嘘の話は消えた? まあ、あるという前提での話になっちゃってるからね。 マイクロソフト太っ腹やなw 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 だからお前よりもわかってるってw 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相当のパフォーマンスになるよ 高速だね! ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる