Custom binfmt.d settings no longer work due to /usr/lib/systemd/system/systemd-binfmt.service.d/wsl.conf setting

[ajkessel]

Windows Version

10.0.19045.4780

WSL Version

2.3.17.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

5.15.153.1-microsoft-standard-WSL2

Distro Version

Ubuntu 24.04.1 LTS

Other Software

Custom binfmt.d settings as shown at https://github.com/ajkessel/wsltools

Repro Steps

I have a bunch of custom binfmt.d settings documented here. With my scripts, the user can launch a Windows executable from WSL and provide a Linux-form path and the correct native path will be automatically passed to the Windows executable without any transformation by the user. My scripts also allow the user to run PowerShell Scripts and Office documents right from WSL by their filenames.

Everything was working fine until recently. I upgraded WSL to 2.3.17.0 and Ubuntu to 24.04.1. I'm not sure which upgrade broke things, but I started noticing these errors in syslog:

systemd[1]: systemd-binfmt.service - Set Up Additional Binary Formats was skipped because of an unmet condition check (ConditionVirtualization=!wsl).

This was never the case before.

I was able to fix it by commenting out the ConditionVirtualization line in /usr/lib/systemd/system/systemd-binfmt.service.d/wsl.conf but this seems like a hack.

Is there any reason that line needs to be there? After commenting it out, everything works fine for me again. There's #8204 which seems to touch on a related issue but I confess I don't fully understand what's going on there.

At the very least, it would be nice to have some documentation clearing up what's going on here. But this was working fine for me before recent upgrades, and commenting out the line in wsl.conf fixed it again for me. Hopefully there is a more systemic fix.

Expected Behavior

Ability to define custom binfmt.d misc lines

Actual Behavior

Binfmt fails due to ConditionVirtualization setting

Diagnostic Logs

N/A

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

Once completed please upload the output files to this Github issue.

Click here for more info on logging
If you choose to email these logs instead of attaching to the bug, please send them to [email protected] with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Closed similar issues:

• Unable to find interpreter for launching .exe files using Interop after enabling systemd (#10239), similarity score: 0.73
• binfmt_misc/binfmt-support not working as expected (#7181), similarity score: 0.72

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[ajkessel]

@
WslLogs-2024-09-09_18-06-56.zip

As requested.

[github-actions]

The log file doesn't contain any WSL traces. Please make sure that you reproduced the issue while the log collection was running.

Diagnostic information

Detected appx version: 2.3.17.0
Found no WSL traces in the logs

[ajkessel]

There is nothing to trace. This is just a systemd setting. Can you please review without a trace?

[elsaco]

The reason is specified in the unit file: systemd breaks WSL interoperability by rewriting the binfmt interpreters configuration So the condition was added to prevent that. Please search open/closed issues and you'll find many reports because the interop was breaking.

[ajkessel]

I must be missing something, because interop is working perfectly with that condition commented out, and until a recent update (either wsl or Ubuntu, I'm not sure which), this was working fine without touching that file.

Is there something more to it than running windows executables from wsl without issue?

[ajkessel]

Or let me ask this another way:

• Is it clear that systemd breaks WSL interoperability in all contexts? It's working fine for me with this line commented out, so perhaps the original diagnosis is overbroad.
• If /usr/lib/systemd/system/systemd-binfmt.service.d/wsl.conf needs to stay as-is, does that mean the end-user must pick between systemd or custom binfmt configurations? They can't have both? Or is there a workaround?

[OneBlue]

@ajkessel: This logic was indeed added to work around systemd-binfmt.service breaking WSL's interop (especially when packages like mono are installed).

You can disable this behavior by adding:

[boot]
protectBinFmt=false

to /etc/wsl.conf and restarting the distro.

This one of the situation where there unfortunately isn't a "perfect" solution that will cover all usecases, but for users with an advanced setup like yours, adding this config entry should resolve the issue.