WSL2: init process consumes 100%

[firewave]

I updated by Windows installation to 2004 and converted my existing Kali installation to WSL 2. Just leaving it running causes an init process to consume 100% CPU all the time. I already closed all applications which make use of my WSL instance (WSL shells, Docker and CLion) and the issue persists.

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
15408 root      20   0    1580    564     16 R  98.0   0.0 150:56.80 init

When attaching strace to that process it just generates an empty log:

strace: Process 15408 attached
strace: [ Process PID=15408 runs in x32 mode. ]

My Windows version is 10.0.19041.264.

[onomatopellan]

Try wsl.exe --shutdown to really shutdown the WSL2 VM.

Also if possible I recommend to uninstall the old Kali distro, run wsl.exe --set-default-version 2 and install again Kali from the store.

[firewave]

I would like to find out what the init process is actually doing. As I mentioned strace gave me nothing and I have no idea what else to do.

I had these issues in the past, but I couldn't keep that state permanent. I still have the same process sitting there after seven days now and could still get any additional information.

[benhillis]

@firewave - An empty strace usually means the program is spinning in usermode, typically a loop with a bad exit condition. Do you have any more detailed instructions so I can try to reproduce this locally? Any output in dmesg?

Thanks!

[firewave]

Thanks for the information.

No idea how to reproduce it - it suddenly was like this. In the future I might come across something, but because of several issues I have to revert to WSL 1 soon, so I wanted to get all the possible information as long as I can.

...
[    0.395709] PCI: Fatal: No config space access function found
...
[    0.469820] kvm: no hardware support
...
[    0.469822] kvm: no hardware support
...
[    0.533293] hv_utils: cannot register PTP clock: 0
...
[    1.615931] FS-Cache: Duplicate cookie detected
[    1.615934] FS-Cache: O-cookie c=000000002773b872 [p=0000000080af89dc fl=222 nc=0 na=1]
[    1.615935] FS-Cache: O-cookie d=0000000022c48e53 n=00000000e5f092ab
[    1.615935] FS-Cache: O-key=[10] '34323934393337343333'
[    1.615938] FS-Cache: N-cookie c=000000003d12a9b2 [p=0000000080af89dc fl=2 nc=0 na=1]
[    1.615938] FS-Cache: N-cookie d=0000000022c48e53 n=000000006b39b3ea
[    1.615939] FS-Cache: N-key=[10] '34323934393337343333'
[    1.617677] FS-Cache: Duplicate cookie detected
[    1.617679] FS-Cache: O-cookie c=000000002773b872 [p=0000000080af89dc fl=222 nc=0 na=1]
[    1.617680] FS-Cache: O-cookie d=0000000022c48e53 n=00000000e5f092ab
[    1.617680] FS-Cache: O-key=[10] '34323934393337343333'
[    1.617683] FS-Cache: N-cookie c=0000000028ee43e6 [p=0000000080af89dc fl=2 nc=0 na=1]
[    1.617683] FS-Cache: N-cookie d=0000000022c48e53 n=00000000dd8d5065
[    1.617684] FS-Cache: N-key=[10] '34323934393337343333'
[    1.619487] FS-Cache: Duplicate cookie detected
[    1.619488] FS-Cache: O-cookie c=000000002773b872 [p=0000000080af89dc fl=222 nc=0 na=1]
[    1.619489] FS-Cache: O-cookie d=0000000022c48e53 n=00000000e5f092ab
[    1.619489] FS-Cache: O-key=[10] '34323934393337343333'
[    1.619492] FS-Cache: N-cookie c=000000003da8cd04 [p=0000000080af89dc fl=2 nc=0 na=1]
[    1.619492] FS-Cache: N-cookie d=0000000022c48e53 n=0000000031549bc6
[    1.619493] FS-Cache: N-key=[10] '34323934393337343333'
...
[   24.947147] FS-Cache: Duplicate cookie detected
[   24.947150] FS-Cache: O-cookie c=000000004746a13b [p=0000000080af89dc fl=222 nc=0 na=1]
[   24.947151] FS-Cache: O-cookie d=0000000022c48e53 n=00000000a51e6039
[   24.947152] FS-Cache: O-key=[10] '34323934393339373636'
[   24.947155] FS-Cache: N-cookie c=000000005ef8f975 [p=0000000080af89dc fl=2 nc=0 na=1]
[   24.947155] FS-Cache: N-cookie d=0000000022c48e53 n=000000002ac5ab97
[   24.947156] FS-Cache: N-key=[10] '34323934393339373636'
[   24.949250] FS-Cache: Duplicate cookie detected
[   24.949253] FS-Cache: O-cookie c=000000004746a13b [p=0000000080af89dc fl=222 nc=0 na=1]
[   24.949254] FS-Cache: O-cookie d=0000000022c48e53 n=00000000a51e6039
[   24.949255] FS-Cache: O-key=[10] '34323934393339373636'
[   24.949260] FS-Cache: N-cookie c=000000005ef8f975 [p=0000000080af89dc fl=2 nc=0 na=1]
[   24.949261] FS-Cache: N-cookie d=0000000022c48e53 n=00000000581333ab
[   24.949262] FS-Cache: N-key=[10] '34323934393339373636'
[   24.951370] FS-Cache: Duplicate cookie detected
[   24.951372] FS-Cache: O-cookie c=000000004746a13b [p=0000000080af89dc fl=222 nc=0 na=1]
[   24.951373] FS-Cache: O-cookie d=0000000022c48e53 n=00000000a51e6039
[   24.951374] FS-Cache: O-key=[10] '34323934393339373636'
[   24.951377] FS-Cache: N-cookie c=000000005ef8f975 [p=0000000080af89dc fl=2 nc=0 na=1]
[   24.951377] FS-Cache: N-cookie d=0000000022c48e53 n=000000004297956f
[   24.951378] FS-Cache: N-key=[10] '34323934393339373636'
[   24.974640] init: (1) ERROR: UpdateTimezone:97: Europe/Berlin timezone not found. Is the tzdata package installed?
[   24.974648] init: (1) ERROR: InitEntryUtilityVm:2425: UpdateTimezone failed
[   25.127372] FS-Cache: Duplicate cookie detected
[   25.127375] FS-Cache: O-cookie c=00000000151abe4a [p=0000000080af89dc fl=222 nc=0 na=1]
[   25.127376] FS-Cache: O-cookie d=0000000022c48e53 n=000000000217a265
[   25.127377] FS-Cache: O-key=[10] '34323934393339373834'
[   25.127380] FS-Cache: N-cookie c=00000000a240dee5 [p=0000000080af89dc fl=2 nc=0 na=1]
[   25.127380] FS-Cache: N-cookie d=0000000022c48e53 n=0000000074715321
[   25.127381] FS-Cache: N-key=[10] '34323934393339373834'
[   25.129556] FS-Cache: Duplicate cookie detected
[   25.129558] FS-Cache: O-cookie c=00000000151abe4a [p=0000000080af89dc fl=222 nc=0 na=1]
[   25.129559] FS-Cache: O-cookie d=0000000022c48e53 n=000000000217a265
[   25.129560] FS-Cache: O-key=[10] '34323934393339373834'
[   25.129563] FS-Cache: N-cookie c=00000000a240dee5 [p=0000000080af89dc fl=2 nc=0 na=1]
[   25.129563] FS-Cache: N-cookie d=0000000022c48e53 n=00000000afb7fc34
[   25.129564] FS-Cache: N-key=[10] '34323934393339373834'
[   25.131727] FS-Cache: Duplicate cookie detected
[   25.131730] FS-Cache: O-cookie c=00000000151abe4a [p=0000000080af89dc fl=222 nc=0 na=1]
[   25.131731] FS-Cache: O-cookie d=0000000022c48e53 n=000000000217a265
[   25.131731] FS-Cache: O-key=[10] '34323934393339373834'
[   25.131734] FS-Cache: N-cookie c=00000000a240dee5 [p=0000000080af89dc fl=2 nc=0 na=1]
[   25.131735] FS-Cache: N-cookie d=0000000022c48e53 n=00000000e38ddec2
[   25.131735] FS-Cache: N-key=[10] '34323934393339373834'
[   25.144448] init: (1) ERROR: UpdateTimezone:97: Europe/Berlin timezone not found. Is the tzdata package installed?
[   25.144455] init: (1) ERROR: InitEntryUtilityVm:2425: UpdateTimezone failed
...
[   25.562415] init: (2) ERROR: UtilCreateProcessAndWait:474: /bin/mount failed with 2
[   25.562560] init: (1) ERROR: UtilCreateProcessAndWait:489: /bin/mount failed with status 0x
[   25.562563] ff00
[   25.562570] init: (1) ERROR: ConfigMountFsTab:2077: Processing fstab with mount -a failed.
[   25.563644] init: (3) ERROR: UtilCreateProcessAndWait:474: /bin/mount failed with 2
[   25.563838] init: (1) ERROR: UtilCreateProcessAndWait:489: /bin/mount failed with status 0x
[   25.563841] ff00
[   25.563848] init: (1) ERROR: MountPlan9:478: mount cache=mmap,noatime,trans=fd,rfdno=8,wfdno=8,msize=65536,aname=drvfs;path=C:\;uid=0;gid=0;symlinkroot=/mnt/
[   25.563851]  failed 17
[   25.564774] init: (4) ERROR: UtilCreateProcessAndWait:474: /bin/mount failed with 2
...
[   42.618780] init: (118) ERROR: LogUsage:253: Could not find owner of socket 2 2222 18438
...
[  491.975531] init: (118) ERROR: LogUsage:253: Could not find owner of socket 2 2222 18438
...
[ 1131.798822] init: (118) ERROR: LogUsage:253: Could not find owner of socket 2 2222 18438
...
[14849.668061] print_req_error: I/O error, dev sdd, sector 0
...
[590035.586381] init: (118) ERROR: LogUsage:253: Could not find owner of socket 2 2222 18438
[590262.296336] init: (118) ERROR: LogUsage:253: Could not find owner of socket 2 2222 18438
[592705.770788] traps: init[12223] general protection ip:22b20a sp:7ffdf0a71590 error:0 in init[225000+6f000]

I assume the socket ones are related to sshd being restarted when I run apt updates. The ones at 25.x seem to early though the timezone one looks interesting. So it seems if anything in the log might be related to this issue it might be the I/O error.

FYI the system is working "fine" aside from the one init process consuming all the CPU.

[onomatopellan]

To rule out a faulty user profile try wsl.exe --shutdown
and launch Kali with wsl.exe -d kali-linux -u root
Does it still happens?

[tuhlmann]

I experience the same thing on my wsl2 Ubuntu 18.04 distro.
It seems to be related to a process from Windows, like IntelliJ Idea, to scan through its project files and re-index them, at least these are the occasions at which I observed this behavior. Shutting down Idea doesn't help.

Also closing every terminal window or user process inside wsl2 doesn't help. wsl --shutdown and then restarting it does help, and the problem would not appear right away, just every so often.

Sorry that I can't be more specific...

[alf-ytakada]

Hi.
I had the same problem after updating to 2004.
On my environment, root cause was Docker for Desktop.
When I uninstall/reinstall Docker for Desktop, I resolved.

[sjoller]

I too have issues with rogue /init processes consuming ~100% CPU, and I'm running an IntelliJ product as well.

My "solution", so far, has been to kill the runaway processes using htop, so a little faster than restarting WSL, but not really a useful solution in the long run, as the offending processes seem to reappear.

[jamestut]

Also happening here on build 21390.2025 and 22000.100 (both on WSL2 Kernel version: 5.10.43). Happens with both WSLg enabled and disabled, and both with and without Docker desktop. Workload is using two VSCode debugging sessions and several Windows Terminal. Only access the 9P (\\wsl.localhost) occasionally when doing Git. When it happens, it just happens randomly and without any adverse effect (besides the rogue init process maxing out a single core CPU time). In this particular instance, it happens well after 3 hours of WSL2 uptime (and keep going strong for around 70 minutes with no sign of stopping!).

Also interestingly, the rogue init process has a PID other than 1! So I can kill it easily using the standard kill -9 command as root. Still annoying though esp. if using the laptop on battery.

Here is the output of ps when it happened.

# > top -d 1
top - 04:23:14 up 12:19,  0 users,  load average: 1.11, 1.27, 1.51
Tasks:  55 total,   2 running,  53 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.9 us,  0.1 sy,  0.0 ni, 86.8 id,  0.0 wa,  0.0 hi,  0.1 si,  0.0 st
MiB Mem :  15932.5 total,  10630.0 free,   4438.1 used,    864.4 buff/cache
MiB Swap:   4096.0 total,   4096.0 free,      0.0 used.  11225.2 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
26502 root      20   0    2468    532      0 R 100.0   0.0  72:53.41 init
17226 user      20   0 1050284 136528  19384 S   2.0   0.8   5:15.55 python3
21651 user      20   0  697468  56224  34836 S   1.0   0.3   0:31.09 node
    1 root      20   0    2116   1468   1016 S   0.0   0.0   3:42.74 init
    7 root      20   0    1752     80      0 S   0.0   0.0   0:00.00 init
    8 root      20   0    1752     88      0 S   0.0   0.0   0:00.43 init
    9 user      20   0  244160   7988   6244 S   0.0   0.0   0:00.70 fish
   79 root      20   0    2364    480      0 S   0.0   0.0   0:00.00 init
   80 root      20   0    2364    480      0 S   0.0   0.0   0:00.19 init
   81 user      20   0   87744   6476   5692 S   0.0   0.0   0:00.00 fish
   83 user      20   0    2624    768    680 S   0.0   0.0   0:00.00 sh
   84 user      20   0    2624    776    688 S   0.0   0.0   0:00.00 sh
   90 user      20   0    2624    776    688 S   0.0   0.0   0:00.00 sh
   92 user      20   0  931860  75384  32020 S   0.0   0.5   1:02.07 node
  103 user      20   0  641720  41440  29848 S   0.0   0.3   1:22.61 node
  114 user      20   0  880532  40780  29556 S   0.0   0.2   0:01.65 node
  134 user      20   0 1026732 165740  39236 S   0.0   1.0   2:53.24 node
  146 user      20   0  178420   7268   5948 S   0.0   0.0   0:00.07 fish
  227 user      20   0 1004504 271784  29836 S   0.0   1.7   0:46.21 node
  253 user      20   0   12.2g   1.5g  39244 S   0.0   9.5  27:30.13 node
  264 user      20   0  925232  64252  29784 S   0.0   0.4   0:10.50 node

As an additional note, it only happens on a single distro (in this case it is Ubuntu 21.04 server WSL image). I got several distros here, all started, but not actively used: only the Ubuntu 21.04 was used actively. Other distros are chilling at 0% CPU usage.

[onomatopellan]

@jamestut With htop in tree mode you can see which process was attached to that init, probably a node one.

[sorgloomer]

I have this issue about once a day. I also use JetBrains products, and the project is on the WSL filesystem, opened via \\wsl$\Ubuntu-20.04\home\person\workspace\... path. I usually just let the instance be started automatically by filesystem accesses.

htop only shows stacked init processes.

c:\workspace>wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu-20.04           Running         2
  docker-desktop-data    Stopped         2
  docker-desktop         Stopped         2

I do not have a definitive repro yet, but it happens quite often to me. Let me know I anybody here has some idea what we could check.

EDIT: The next day. I have the same morning routine, turn on the machine, open chrome, attend meeting, and fire up WebStorm on a \\wsl$\ folder, which in turn fires up WSL. High cpu init is there, again. But this time only one process.

Restarting WebStorm fixes it, that init process stops. What is interesting, if I close everything and shut down WSL2, and start WebStorm again, it does not happen again. It only happens after I reboot the laptop.

[sorgloomer]

I attached GDB to one of the runaway init processes, it looks like its stuck in a very short loop, around:

(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x000000000022ae8f in ?? ()
(gdb) bt
#0  0x000000000022ae8f in ?? ()
#1  0x000000000125fd30 in ?? ()
#2  0x00000000000000a0 in ?? ()
#3  0x0000000000000004 in ?? ()
#4  0x0000000000000090 in ?? ()
#5  0x0000000001259390 in ?? ()
#6  0x0000000001259410 in ?? ()
#7  0x00000000012593a0 in ?? ()
#8  0x0000000000000080 in ?? ()
#9  0x0000000000000000 in ?? ()
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x000000000022ae20 in ?? ()
(gdb) bt
#0  0x000000000022ae20 in ?? ()
#1  0x000000000125fd30 in ?? ()
#2  0x00000000000000a0 in ?? ()
#3  0x0000000000000004 in ?? ()
#4  0x0000000000000090 in ?? ()
#5  0x0000000001259390 in ?? ()
#6  0x0000000001259410 in ?? ()
#7  0x00000000012593a0 in ?? ()
#8  0x0000000000000080 in ?? ()
#9  0x0000000000000000 in ?? ()
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x000000000022af10 in ?? ()
(gdb) bt
#0  0x000000000022af10 in ?? ()
#1  0x000000000125fd30 in ?? ()
#2  0x00000000000000a0 in ?? ()
#3  0x0000000000000004 in ?? ()
#4  0x0000000000000090 in ?? ()
#5  0x0000000001259390 in ?? ()
#6  0x0000000001259410 in ?? ()
#7  0x00000000012593a0 in ?? ()
#8  0x0000000000000080 in ?? ()
#9  0x0000000000000000 in ?? ()
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x000000000022ae80 in ?? ()
(gdb) bt
#0  0x000000000022ae80 in ?? ()
#1  0x000000000125fd30 in ?? ()
#2  0x00000000000000a0 in ?? ()
#3  0x0000000000000004 in ?? ()
#4  0x0000000000000090 in ?? ()
#5  0x0000000001259390 in ?? ()
#6  0x0000000001259410 in ?? ()
#7  0x00000000012593a0 in ?? ()
#8  0x0000000000000080 in ?? ()
#9  0x0000000000000000 in ?? ()
(gdb)

...

$ sha256sum /usr/sbin/init
72190cb5c04e9cc370afa91721d67e070677bbefe874b69dd76ccb86e8188c8c  /usr/sbin/init

@onomatopellan please tell me what other information can I provide.

[Radrik5]

I experience slowness in Git Extensions running on Windows with repo in WSL 2, init process in WSL consumes more that 100% CPU.

I found an easy way to reproduce the issue: clone WSL2-Linux-Kernel and run 'git status' from Windows.

In WSL2 Ubuntu:

$ git clone -b linux-msft-wsl-5.10.y https://github.com/microsoft/WSL2-Linux-Kernel

In Windows console:

> subst x: \\wsl$\Ubuntu
> x:
> cd home\<user>\WSL2-Linux-Kernel
> git status

[derekrprice]

@tuhlmann said:

I experience the same thing on my wsl2 Ubuntu 18.04 distro. It seems to be related to a process from Windows, like IntelliJ Idea, to scan through its project files and re-index them, at least these are the occasions at which I observed this behavior. Shutting down Idea doesn't help.

I am seeing that with Ubuntu 20,04. I closed PHPStorm (closely related to IntelliJ), and the problem went away. I think that they can be at least one cause for this problem.

[lukasamd]

@derekrprice yep, it's their problem.. or just problem with communication between windows and WSL filesystem
I've used phpStorm from WSL instead of Windows for about 2 months and didn't see that issue anymore

[PioPh]

I've been having this issue as well.
In my case it seems to be an issue particularly with Windows Terminal (wt.exe) opening wsl as the default profile.
Opening wsl with cmd.exe, powershell.exe or wt.exe with anything else as the default profile then running wsl does not have the same init behaviour.

Windows 10 19044.1415 21H2. WSL 2. Kali-linux.

[romkatv]

Just as @PioPh described: opening a WSL tab in Windows Terminal causes 100% CPU usage by /init, but opening a Command Prompt tab and manually running wsl.exe from it works fine. This is with WSL1. Reboot doesn't help. Reproducible every time. Started happening very recently -- some time this week. Opening N WSL tabs consumes 100% of N CPU cores.

[marchelzo]

Yep exactly the same for me. Started about two weeks ago out of nowhere after a Windows update I believe.

[g4b0]

Same problem on my workstation, with ubuntu 18 and wsl2. Like @romkatv it just happens opening a tab in Windows Terminal

[romkatv]

I've asked my friends and it appears that the problem reproduces for everyone:

1. Make Ubuntu 20.04 the default distro in WSL (either WSL1 or WSL2 -- doesn't matter).
2. Open a new WSL tab in Windows Terminal.
3. Observe that one CPU core is now at 100% load.

The version of Ubuntu doesn't seem to matter. It's possible that the choice of distro also doesn't matter.

Edit: There is one more necessary step:

4. Set startingDirectory to /home/USERNAME in Windows Terminal settings.

[myndbreaker]

I had success fixing this with resetting the Userhome Path in Windows terminal to default and then back to my wsl Userhome.
The only Difference I could spot with the userhome Path was the Change from Slashes to Backslashes
\wsl$\Debian\home\USERNAME

[romkatv]

Confirmed. Opening a WSL tab in Windows Terminal when startingDirectory is set to /home/romka results in 100% load of one CPU core. Doing the same when startingDirectory is \\wsl$\Ubuntu-20.04\home\romka works fine.

I've changed startingDirectory from //wsl$/Ubuntu-20.04/home/romka to /home/romka recently, when the former stopped working. I suppose that's when 100% CPU load started happening.

[colomb8]

quick and dirty fix, waiting for the real fix:

• comment "startingDirectory" in settings.json
• add "cd ~" at the end of .bashrc

[cmsavage]

Confirming that the Windows Terminal starting directory was the issue for me (WSL, Ubuntu 18.04): changing from //wsl$/Ubuntu-18.04/home/username to \\wsl$\Ubuntu-18.04\home\username stopped the excess CPU usage.

If you use the "open windows from previous session" as your Windows Terminal startup mode, the issue will come back for any sessions that you started prior to fixing the starting directory. Close each of those and start new sessions once, then they should work correctly upon Windows Terminal restart.

[sorgloomer]

Fyi on none of my machines was I able to reproduce the issue for the past couple of months. High CPU usage stops after 1-2 minutes, it is practically indistinguishable from boot load in my case now (previously it didn't stop on itself, not even after 30 minutes).

Edit: just after I wrote this, it started happening again, quite reliably, I am finding init processes with 19h CPU time even though I restart the machine every day.

[kstauffer]

I think I've figured out the problem. I don't know what's wrong with Windows Terminal (I'm using Preview 1.12.3472.0), but here's how to work around it.

TL;DR

In your Terminal profile, the starting directory must be null or a UNC path -- no forward slashes allowed! null will put you in /mnt/c/WINDOWS/System32, which is weird. I suggest you use (the UNC path to) your WSL home, like \\wsl$\Ubuntu-20.04\home\kstauffer. This is the path used when you start Terminal, or open a new window with ctrl+shift+n, or open a new tab with ctrl+shift+t. (If you use the duplicateTab action instead, make sure you read the next section).

Fix your shell

Now, to fix how the shell is reporting the current working directory to Terminal. This is the directory that is used by Terminal for the duplicateTab action, overriding the profile's value of startingDirectory. I used to have this in my .bashrc: PROMPT_COMMAND="echo -n \$'\e]9;9;'\"\$PWD\"\$'\e\\\\'"
Of course, $PWD is a WSL path. The fix is to map that WSL path to its UNC equivalent, with backslashes (not forward!): replace $PWD with wslpath -w $PWD. Suitably escaped for the various levels of quoting and evaluation, you get: PROMPT_COMMAND="echo -n \$'\e]9;9;'\"\$(wslpath -w \$PWD)\"\$'\e\\\\'"

Make sure you don't also have a \e]9;9;... sequence in your PS1, or adjust it accordingly.

Details

If the startingDirectory in your profile (or the path most recently reported by the shell via \e]9;9; at the moment you invoke duplicateTab) begins with a forward /, then you are in for a rough ride. Terminal will interpret a leading / as a WSL path, with various bad outcomes:

• If that path is "/path/to/exists", your shell will start in that directory, but init will spin at 100%.
• If that path is "/", Terminal will actually use C:\ (at least for me), which inside WSL is /mnt/c. CPU will be at 0%. (Yay? But you're not in /, you're in /mnt/c, so that's weird)
• If that path is "/path/to/bad" which doesn't exist in WSL, your shell will start in "/" instead (actually / this time, not /mnt/c) and init spins at 100%. This also covers the case where people were using bogus "UNC" paths with forward slashes, like //wsl$/Ubuntu-20.04.
• If that path is a Windows path (e.g. C:\Windows) or a UNC path to your WSL filesystem (starts with e.g. \\wsl$\Ubuntu-20.04), your shell will start in the correct directory inside WSL, and init will be idle! 🍰

[daiwei233]

I hava the same problem, and I didn't use any software about Intellij.

dirty solve

I found some other ways, and it works fine for me:

• Open the terminal with ubuntu 20.04
• ssh {any host}

ssh any host, what ever.

• Kill the init process by Windows Task Manager

Now I got a new problem that I can't use ctrl+c.

strace

It seems to fall into the dead cycle, looking forward to official solution

--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
....

[vvaltchev]

I agree with @kstauffer that the problem is related with the starting path. Init began to consume 100% of one CPU after I changed the starting path to /home/vlad. Therefore, I restored the old value and I just added a simple "cd" at the end of my .bashrc file. That was my workaround.

[kstauffer]

@vvaltchev Did you try setting the starting path to the Windows equivalent of \\wsl$\Ubuntu-20.04\home\vlad (backslashes and the odd prefix included)? Change Ubuntu-20.04 to whatever distro you're using. That fixed it for me, it would be interesting to see if that also works for you.

[vvaltchev]

@kstauffer I just did. Using \\wsl$\Ubuntu-20.04\home\vlad works well, as expected. Init doesn't burn the CPU. Just, it has syntax pretty hard to remember 😄

[Tofandel]

It seems there is two problems then, one with jetbrains and one with startDirectory, I'm experiencing the first but not the later

So if you have a problem with high CPU and are running an instance of PhpStorm WebStorm or any other jetbrains product from time to time, some git tasks or indexing task seems to get stuck, in which case restarting the stuck instance is enough to solve it

Can't speak for startDirectory

[Robula]

It seems there is two problems then, one with jetbrains and one with startDirectory, I'm experiencing the first but not the later

So if you have a problem with high CPU and are running an instance of PhpStorm WebStorm or any other jetbrains product from time to time, some git tasks or indexing task seems to get stuck, in which case restart the stuck instance is enough to solve it

Can't speak for startDirectory

I use JetBrains products also and I'm having the same issue with /init running away on a single core, I also notice Git inside the JetBrains IDEs either crashes or is just incredibly slow. Have these issues been reported on https://youtrack.jetbrains.com/issues?

[derekrprice]

@Robula, I found this one: https://youtrack.jetbrains.com/issue/CPP-23933/WSL-1-init-process-consumes-a-lot-of-CPU

[Tofandel]

Hit this again today and no luck killing it this time, I had to restart the LXSSManager service
Edit: Forgot to sudo htop

What's even more scary is that it doesn't show up in the Task manager and this cpu usage is only visible with htop in wsl, so my computer was getting crazy hot to the point of burning and I couldn't figure out why. This seems like this could be a big security issue as well, as there is no visibility on the CPU usage of wsl from windows

[sorgloomer]

Okay, I have a suspicion, but nothing is proven yet. I started to think Jetbrains products can get stuck in some loop when using Git on the Windows host to analyze repositories on \\wsl$\. I personally don't use the git cli on Windows, I use git from a WSL2 terminal, but I have set it up so the tools running on the Windows host, like Jetbrains products, have it available.

Today I had the CPU usage issue again, so opened up Procexp and saw that Webstorm was firing up many git subprocesses per second in a loop. Keep in mind, Webstorm is running on Windows, but the project files live in \\wsl$\, and I also use git from WSL2.

I just learned that Jetbrains has WSL2 git support, so I changed Webstorm settings to use git from WSL2 (as described here: IDEA-172253) and the problem went away for now.

UPDATE: didn't take long, the CPU usage came back, so this seems to be a sidetrack.

[Tofandel]

@sorgloomer it's unlikely this will solve the issue, as like you I'm running jetbrains from Windows on a project in WSL, but I've already always been using the git from WSL and not Windows and still had this issue. Except its even worse because then the cpu of WSL git doesn't show on Windows task manager

[TonalidadeHidrica]

I ran into the same issue (busy init process of pid 1) but neither JetBrains nor startingdirectory seems the root issue†. I ran

taskkill /IM explorer.exe /F
explorer.exe

successively then the rogue init process immediately stopped consuming 44% CPU. (Yes, I delibarately used a codeblock to catch your eyes who are seeking for another solution ;) I came up with an idea of killing explorer because, on one hand you guys mention that it is due to disk access, and on the other hand I had tried copying a relatively large directory from WSL to C drive, which ended up in a stop of copying halfway done, before which I responded to a strange warning of duplicated files (it shuold not happen when copying a directoly alone, right?) with admitting overwriting files.

† I am not using JetBrains at all, and also I doubt it is due to Windows Terminal simply because such an issue never happened during my few months experience in Windows terminal.

[jarppiko]

I came by the same issue. In my case the setup was the following:

> wsl --version
WSL version: 1.0.3.0
Kernel version: 5.15.79.1
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.963

Linux OS was Ubuntu 22..04.1 updated from 20.04 through do-release-upgrade. In my case the init process got triggered by systemd = true setting in /etc/wsl.conf.

I managed to overcome the issue by making a fresh install of Ubuntu 22.04.1 LTS from Microsoft Store as a second instance. That does not have any issues with the systemd = true setting. I am now in process of migrating my VM content to the new instance.

[wywywywy]

@jarppiko It was mentioned over here #9029 that removing acpid would resolve the issue, and it did for me.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!