The Truth About Systemd Under WSL2

[@MrNoBSgiven]

Mike, I believe you are missing one big difference between WSL and the independent Unix machine and the main purpose - WSL is to be uxed as a development environment and not production. Missing Systemd didn 't allow for full testing of unix scripts, programs (like your python based service). Now it does. Let's not corget that you are using it on laptop computer, which in its nature assumes lack of uninterruptible access by the externap world. BTW, docker images also lack support for systemd by default. Some folks created own,mhacked versions, so it is possible for github actions to test ansible scripts, which affect system services installation procedures. Sometimes we have a tenency to overcomplicate thinks and forget about the K.I.S.S. rule. Notice how many websites run on wordpress instead of being static. For example, I could not understand the attraction to products like Hugo or Gutsby by many folks, but finally got it. I was concentating on flexibility instead of the main functionality I needed. I think, you are making the same thing. If you need a constantly running services, put them onna dedicated machines (virtual, physical). If you shut down VM, lxd container like you do WSL, they will also disable systemd, won't they? 😉

[@MikeLevin]

Just to clarify, you're saying that systemd under WSL on a laptop should be different than systemd not under WSL? So, one behavior for Microsoft-based Linux and another behavior for "genuine" Linux? And no, WSL will not exit it you use one of the systemd hacks out there like distrod. Moving to native systemd was a step backwards. And no, LXD does not stop running when the host machine closes terminals to it. It stays running always in the background, as do its systemd tasks. I think the position that WSL exits when terminals close is untenable. Microsoft's killing WSL instances deliberately in for some reason contrary to the concept of Linux daemon.

[@davidcopenhaver5583]

Totally agree, when considering what WSL is meant for, this is completely expected and acceptable behavior. For Mike's use case a full VM seems more fitting.

[@MikeLevin]

Why would you incur the overhead of a whole VM when WSL is built into windows? I'm not sure why the option that exists to activate systemd just doesn't work. I would accept it as a default, but not as zero option.

[@LukeAvedon]

Absolutely fascinating video Mike!

[@MikeLevin]

Thanks. It's funny to learn. Wait 8 seconds and FREEZE! I couldn't figure out why Jupyter kept stopping when I quit the last terminal. I had to put 2 and 2 together just to figure out that's what was going on.

[@davidcopenhaver5583]

that's exactly how I would expect it to behave.

[@EnavSounds]

Great video, you look like a cool dude to share a joint with.

[@syedwasifsimnani2776]

I had the same issue with the nginx server after enabling systemd. At first, I thought it was a bug and tried searching for information about it, but found nothing. Finally, I found this video which talks about the issue. It is very annoying to have to keep the terminal open for the instance to keep running."

[@MikeLevin]

I believe it is one the biggest tech issue of our day that systemd has finally come to Windows via Microsoft… broken. I'm glad that there's at least one other person who sees this.

[@juanbaromance]

IMHO To consider the systemd framework alive only under the surveillance of a terminal is more than a naive approach

[@MikeLevin]

Exactly! It could open the door to so much innovation on the Windows platform.

[@eusamuel]

Who'd truly expect Microsoft to prioritize WSL background processes? I mean sure there could be a switch to make it happen but to expect it to be on by default is too much

[@MikeLevin]

Okay then how about not on by default but able to be turned on (to stay on)? I think the current implementation underestimates how much of our tech world actually runs on Linux daemons.

[@eusamuel]

@@MikeLevin Yes able to be turned on and stay on is reasonable.

[@MikeLevin]

I would like someone to report to me if this is possible. I've tried: [wsl2] vmIdleTimeout=600000 ...in a .wslconfig file under Windows home and even did wsl --shutdown to try to get it to stick, but nothing I try stops Windows from nuking all Linux daemons after about 8 seconds. I'm open to overriding this behavior cleanly, but am currently testing hacks like detached sleep commands that never return, but I shouldn't have to. Hosting Jupyter under Linux is the definition of reasonable expectation for systemd under wsl.