udev_monitor_enable_receiving returns EINVAL

[arcanis]

Now that #758 is fixed, another error prevents running Electron apps (tested w/ hyperterm & atom):

arcanis@DESKTOP-819ATN1:~$ DISPLAY=localhost:0.0 atom                                                                                                                                                                                       
libGL error: No matching fbConfigs or visuals found                                                                                                                                                                                         
libGL error: failed to load driver: swrast                                                                                                                                                                                                  
[6186:0925/155804:FATAL:udev_linux.cc(29)] Check failed: 0 == ret (0 vs. -22)                                                                                                                                                               
#0 0x000001bfb0ae <unknown>                                                                                                                                                                                                                 
#1 0x000001c10f3b <unknown>                                                                                                                                                                                                                 
#2 0x0000026aceeb <unknown>                                                                                                                                                                                                                 
#3 0x000002404e95 <unknown>                                                                                                                                                                                                                 
#4 0x000001bfbd6f <unknown>                                                                                                                                                                                                                 
#5 0x000001c1764b <unknown>                                                                                                                                                                                                                 
#6 0x000001c17b8b <unknown>                                                                                                                                                                                                                 
#7 0x000001bf1209 <unknown>                                                                                                                                                                                                                 
#8 0x000001c2b660 <unknown>                                                                                                                                                                                                                 
#9 0x000001c16eaa <unknown>                                                                                                                                                                                                                 
#10 0x0000023dbfa6 <unknown>                                                                                                                                                                                                                
#11 0x0000023dc0d7 <unknown>                                                                                                                                                                                                                
#12 0x000001c4ba38 <unknown>                                                                                                                                                                                                                
#13 0x000001c47d4d <unknown>                                                                                                                                                                                                                
#14 0x7fc4984176fa start_thread                                                                                                                                                                                                             
#15 0x7fc491d76b5d clone                                            

I digged a bit, and apparently it's because of the udev_monitor_enable_receiving function returning -22, which appears to be EINVAL.

[fpqc]

Yeah lol, udev doesn't even run at all. Right now devfs is practically hardcoded in the init executable (this is actually the only Microsoft ELF64 file that gets dropped into

%localappdata%\lxss\rootfs

If you delete it, it gets regenerated. I don't know what they're going to do about systemd and udev. Right now all that stuff that gets set up by udev (devfs in /dev for example) is basically hardcoded into the init binary. I don't even know how it's generated, or even which compiler and libc they're using to create it. It's very mysterious, and it seems like a hack, but I have no idea, since I've never reverse engineered anything before. I did hear that it actually does two different things right now, depending on what PID it's launched as. If you run it as any PID other than PID 1, it is actually the mysterious /usr/bin/winrun (which is a symlink to /init). Otherwise, it does something completely different, namely initializing the LX instance, setting up /dev and /proc and what have you. Hopefully we'll hear more about it in the future.

[therealkenc]

/init is just a Linux ELF64 binary, just like any other. The only thing special about it is (a) it's written by Microsoft, (b) it talks to the Windows lxssmanager service though the IPC channel (/dev/lxss), a device which doesn't exist on native Linux.

Other than that:

/$ sudo file init
init: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, 
    interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24,
    BuildID[sha1]=6bbae786cbf484441e892bd0b7cf48a787b98338, stripped
/$ sudo ldd init
        linux-vdso.so.1 =>  (0x00007fffd1599000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f69ad210000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f69ada00000)

It's even dynamically linked with glibc. Which is actually kind of ballsy - I thought it was traditional to statically link init.

As for electron, udev is relatively simple to configure away in the source. That's not what is critically blocking Atom or VS Code (which is just another way of saying 'Google Chrome') right now.

[fpqc]

@therealkenc I dropped it into a hex editor, and init does a lot of stuff. It's actually a weird kind of reverse console host. The WSL TTYs are, weirdly, sort of like sockets on init, which is kind of like a daemon that marshals all of the TTY I/O through the bus (which it binds exclusively). Makes sense, since the Windows kernel would never directly display a tty. That's also why init is going to launch Windows programs back through the bus.

I'm a little bit worried about the fact that so much of the i/o infrastructure for WSL is going to be shoved into the init executable, since it might be difficult for them to switch to something like systemd and udev. Not too sure though. I guess we'll see.

Edit: Thinking about it more, since init is creating the ttys using the bus, you might be able to ape the WSL init with custom udev rules. Need to read up a bit more how udev rules work and when it gets started up by systemd.

[therealkenc]

Don't get too hung up on udev or systemd. It's kind of a side-show really. The native Linux kernel proper technically doesn't care if udev exists either. It's a userspace library (libudev) that receives messages from the kernel over AF_NETLINK -- assuming anything is there to listen. It is this WSL kernel netlink surface that is missing. Other Linux distros like Android don't have systemd. That is, udev is a "Ubuntu etc thing" not a "Linux thing".

In fact because libudev is just a userspace library, you can totally just stub udev and make the rest of userspace happy. I just about did that for the Chrome port, but it turns out you can just configure it away (with some work) because Android, ChromeOS, OS X, and embedded environments have never heard of it. The chromium content library on Debian/Ubuntu annoyingly uses it to see if usb thumb drives, usb bluetooth headsets, and usb cameras have come and gone.

Sooner or later it seems to me they are going to have to get out of the way of 'real init' on PID 1 (where God intended it) if they want to remain distro-agnostic. But since right now 'real init' on Ubuntu means systemd, that's premature until enough of the kernel netlink protocol is implemented or stubbed enough to make systemd happy.

[therealkenc]

The OP here was:

[6186:0925/155804:FATAL:udev_linux.cc(29)] Check failed: 0 == ret (0 vs. -22)   

Which was addressed with the NETLINK_KOBJECT_UEVENT work in 16273.