WSL needs to handle (some) init steps

[bitcrazed]

• Your Windows build number: (Type ver at a Windows Command Prompt)
  10.0.17007.1000

• What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)
  Starting tmux in openSUSE & SLES

• What's wrong / what should be happening instead:
  tmux fails with the following error:

> tmux
can't create socket: No such file or directory

Originally raised this problem in tmux/tmux#1092, but looks to be a WSL issue:

• Strace of the failing command, if applicable: (If <cmd> is failing, then run strace -o strace.txt -ff <cmd>, and post the strace.txt output here)

tmux-trace.55.txt

strace above ends with tmux attempting to create socket in /run/tmux which fails because /run/tmux doesn't exist, because WSL nukes tmpfiles when closing a session, and doesn't (yet) re-init tmpfiles on startup.

See the following post on details as to why systemd distros are moving to adopt /run/ for new tempfiles: Linux distributions to include /run/ directory

• Potential workaround/solution

IF one runs systemd-tmpfiles from within SUSE, the requisite folders will be created as expected. We should also look into what other systemd init tasks we should consider running.

rich@Vimes:~> tmux
can't create socket: No such file or directory
rich@Vimes:~> ls /run
lock  shm  user
rich@Vimes:~> sudo systemd-tmpfiles --create
[sudo] password for root:
[/usr/lib/tmpfiles.d/tmp.conf:16] Failed to replace specifiers: /tmp/systemd-private-%b-*
[/usr/lib/tmpfiles.d/tmp.conf:17] Failed to replace specifiers: /tmp/systemd-private-%b-*/tmp
[/usr/lib/tmpfiles.d/tmp.conf:18] Failed to replace specifiers: /var/tmp/systemd-private-%b-*
[/usr/lib/tmpfiles.d/tmp.conf:19] Failed to replace specifiers: /var/tmp/systemd-private-%b-*/tmp
rich@Vimes:~> ls /run
dirmngr  lock  log  screens  shm  systemd  tmux  uscreens  user
rich@Vimes:~>

Suggest that WSL considers running at least some key init processes when starting a new session.

[fpqc]

I wonder if it wouldn't be simpler to actually run systemd in its container mode (used in rkt and nspawn). You already suppport almost all of the syscalls, you just need to rewrite WSL-init's marshalling functions into a systemd daemon

[therealkenc]

Suggest that WSL considers running at least some key init processes when starting a new session.

WSL doesn't have the foggiest idea what init processes are "key". On Alpine, systemd-tmpfiles is not a thing.

[fpqc]

The big systemd discussion mentioned that there is a way to hand control over from WSL-init to systemd once the environment is set up. Some Linux distros pre-initialize with busybox, then hand over pid 1 to systemd. This is probably the ideal solution.

[marcthe12]

Thats the initrdfs. Its a ram disk used to bootstrap the file system. Especially useful when you need some userspace commands before init can run. Maybe we should see if wsl init could become an initrdfs

[therealkenc]

Some Linux distros pre-initialize with busybox, then hand over pid 1 to systemd.

Yes, but said distros are running on a Linux kernel compiled with the ABI necessary to support systemd. We are not. [As folks running on a Real Linux kernel compiled without say CONFIG_CGROUPS=y are likewise not.] And there is the rub. pivot_root(2) isn't the blocker. We already have that.

[marcthe12]

but said distros are running on a Linux kernel compiled with the ABI necessary to support systemd

Well Systemd itself does not work but what about other inits. They may have similar solution to the issue. Plus As mention above, Its best to move as much as possible of the WSL to initrd.

[fpqc]

@therealkenc yes, I am aware! But my point was that since we are talking to Rich, rather than a user, it is probably a lot easier now for them to just finish supporting the kernel surface required for systemd and use it rather than try to rewrite their own init to do more and more things in a distro-independent way (which is basically reinventing systemd).

[therealkenc]

kernel surface required for systemd

Well... yeah. Implementing missing system surface is always a Good Thing™. But that isn't exactly a news flash. No one needs a "heads up" on that.

systemd is subject matter #994, not this thread. "Other inits" per Marc aren't germane to this thread either, because other inits aren't going to call systemd-tmpfiles out of the box, and thus are of no use to Rich's immediate ask. Whether WSL pivots to systemd (or something else) after an initrdfs (or equivalent) isn't relevant either, because tmux doesn't know the pivot ever happened. Outside the box you can do just about anything of course. You can pivot another init right now if you are willing to go off-road. But that is kind of beside the point too.

The only point I was making in the context of this thread is that quoth: WSL doesn't have the foggiest idea what init processes are "key".

[eode]

tmux works for me (have latest updates).

[therealkenc]

Recent-ish tmux (for some value of 'recent') creates the needed /tmp entry on startup if it is missing. Mine happens to be 3.0a. (package 3.0a-2ubuntu0.2). Chalking external feature request tmux to be more tolerant of missing systemd, which the tmux devs look to have graciously satisfied. That change is also useful for other container scenarios (like docker) besides.

This submission ended up a dupe target for a WSL /init death march to provide "some key init processes". More plausibly, follow #994 which can maybe evolve into a better native init/systemd story on WSL.

[tosigus]

On openSUSE Leap 15.3 is tmux (3.1c) not working without sudo systemd-tmpfiles --create when WSL is started. Ubuntu works fine.

[didibus]

Same issue with openSuse Tumbleweed and tmux 3.2:

error creating /run/tmux/1000 (No such file or directory)

Adding:

# Fix for tmux on openSuse with WSL2
export TMUX_TMPDIR='/tmp'

in my .zshrc did the trick to fix it though.

[tosigus]

Same issue with openSuse Tumbleweed and tmux 3.2:

error creating /run/tmux/1000 (No such file or directory)

Adding:

# Fix for tmux on openSuse with WSL2
export TMUX_TMPDIR='/tmp'

in my .zshrc did the trick to fix it though.

Hooray! Adding it to .bashrc works. Thanks!