updated: WSL commands freeze when Docker Desktop's "resource saver" is on and autoMemoryReclaim=gradual

[jtabox]

Windows Version

Microsoft Windows [Version 10.0.22621.2792]

WSL Version

0.0.0.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

5.15.133.1-1

Distro Version

Ubuntu 22.04

Other Software

Not really sure there's some interaction with other programs.

Repro Steps

I can't exactly reproduce the bug as it seemingly happens "randomly", though always when I run any disk-related command from zsh.

Expected Behavior

Expecting those commands to not freeze to the point of me having to restart WSL.

Actual Behavior

I'm posting here in case someone more knowledgeable can tell me where to look because I'm not sure what I can do.

So, the last couple of weeks I started experiencing some shell commands "freezing" when trying to run. Specifically commands that are related to disk i/o I think (e.g. ls, lsof but even apt update/upgrade when they need to use the disk).

What happens after I write the command and press enter: The cursor moves to new line as expected, but after that it stays there, and nothing happens in the terminal. It doesn't freeze completely, the cursor is still blinking, and I can enter key sequences (though usually any Ctrl-C commands show up as ^C). Sometimes I can interrupt and go back to the prompt with Ctrl+C, and more often the only solution is to do a wsl --shutdown from a Windows cmd prompt.

Opening a second WSL terminal when this happens and running the same (or other disk related) command results in the same behavior. Opening a third terminal and running top/htop (it runs fine), I can see my shell processes and the failing commands in state D (uninterruptible sleep). I recently learned about set -x so I tried it and ran a "faulty" command. It outputs some stuff initially, but then stops and freezes in a read/write line.

At this point I'm suspecting they're waiting for some locked file to unlock or some signal from the disk or something similar? I haven't been able to figure out any connection with any other programs. I've checked WSL's ext4.vhdx file with e2fsck and it doesn't return any errors. Everything else works fine in my PC when this happens, no increased CPU usage or anything out of the ordinary.

Aaaand somewhere here ends my troubleshooting ability for Linux, so I have no idea if there's a way to figure out what is happening. Like if it's some other program that holds a file locked or the disk or whatever. I collected some logs that I paste below, they don't seem out of the ordinary with my inexperienced eye.

Thanks in advance for any tips.

Diagnostic Logs

WslLogs-2023-12-10_23-36-02.zip

[OneBlue]

Thank you @jtabox. I'm not seeing anything that jumps out. I wonder if you try to remove autoMemoryReclaim=gradual from .wslconfig, then run wsl.exe --shutdown, and see if solves the issue.

[jtabox]

Will try it, @OneBlue . Should I disable it completely or can I change it to autoMemoryReclaim=dropcache?

[OneBlue]

Will try it, @OneBlue . Should I disable it completely or can I change it to autoMemoryReclaim=dropcache?

I'd be curious to see both.

[jtabox]

Haven't had a lot of time available for testing, from the little testing I've done with only autoMemoryReclaim=dropcache I'm not getting the issue so far.
But as I said, it's still early, will need to try with autoMemoryReclaim completely off too.

[jtabox]

So, I've been testing with autoMemoryReclaim=dropcache and the issue hasn't reappeared so far, so I assume the gradual memory reclaim was somehow related? Or how come you suggested this solution @OneBlue ?
I'm not so well familiar with the whole memory reclaim issue in WSL, but I assume having autoMemoryReclaim on in some way is beneficial, no? I mean it's preferrable than deactivating it completely? Is there any drawbacks using the dropcache alternative vs the gradual one? At least in a home environment.

[jtabox]

See #11066 for more info. Should I close this issue and let the new one up, since it has more updated info?