tail -f は WSL 上のファイルを追跡しません

tail -f は WSL 上のファイルを追跡しません

私は持っている :

F:\xampp-htdocs>wsl --list
Windows Subsystem für Linux-Distributionen:
Ubuntu-22.04 (Standard)

Windows 11 のログファイルに cd します:

/mnt/d/xampp-2024-15-01/apache/logs$

そこに私はいます

tail -f access.log

tailは最後の行を出力するだけで、その後はファイルに追従しなくなります。WSLとWindows11内の異なるファイルでこれを試しました。運がありませんでした。

リモートの外部の実際の Ubuntu "20.04.6 LTS (Focal Fossa)" システムでは、tail -f期待どおりに動作します。

何が足りないのでしょうか?

答え1

根本的な問題は、inotifyAPI が、Windows ドライブへのアクセスに WSL2 で使用される Plan 9 (9P) ネットワーク ファイル システムでサポートされていないことです。これは、 などの機能tailや、多くの開発ツール (など) の「ホット リロード」機能に影響しますnpm watch

これは、WSL2 で次の場合に発生します。

  • Linuxアプリはinotifyファイルシステムの変更を監視するために使用しようとしています(この場合はもちろん、tail -f
  • ファイルはWindowsドライブにあります(おっしゃるとおり/mnt/d
  • (私はかなり確信しています) Windows プロセスがファイルに書き込みを行っています。WSL2 で Linux プロセスを使用してファイルを拡大すると (例)、私の場合はecho foo >> file_nameの更新が成功します。tail -f

通常の回避策:

  • 可能であれば、ファイルを Linux ファイルシステムに保存します。これは可能な場合もあれば、不可能な場合もあります。

  • アプリがサポートしている場合は、代わりにポーリングを使用しますinotify。この場合、SOの回答@KamilMaciorowski がコメントで指摘した、 で完了しましたtail -f ---disable-inotify <file>が、どの回答も役に立たなかったと返信しました。

    これできた使用された回答とは異なるバージョンのためである可能性がありますtail。再試行間隔を追加することもできます。

    tail -f ---disable-inotify -s 1 <filename>
    
  • これまでの「伝統的な」提案は、ユースケースに適している場合は WSL1 を使用することでした。ただし、WSL1 はここ数年更新されていないため、その使用を正当化することが難しくなっています。それでも、それは選択肢として残っています。WSL1 では、inotifyWindows ドライブで動作します。

  • 具体的にはtail、ちょっとしたハッキーな回避策を実行できます。

    pwsh.exe -c 'Get-Content <windows_path_to_file> -wait'
    

    ノート:

    • PowerShell Core がインストールされていない場合は、(推奨) インストールするか、代わりに を使用しますpowershell.exe

    • 前述のように、WSL内からPowerShellを使用するので、ウィンドウズファイルへのパス。例: D:\xampp-2024-15-01\apache\logs$.

    • シェルをネストする場合、引用/エスケープは困難になる可能性があります。

    • クレジットこのSOの答えのために-Wait

    • もちろん、これをエイリアス化したり、シェル関数またはスクリプトでラップしたりすることもできます。

関連情報