<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 29, 2023, 20:59 Thomas Larsen Wessel <<a href="mailto:mrvelle@gmail.com">mrvelle@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks both of you! :)<div><br></div><div>I have taken some time to digest your answers. And in particular I have tried to investigate this line closer:</div><div><br></div><div><i>Nov 27 12:34:22 tumbleweed unknown: WSL (2): Creating login session for andrei</i><br></div><div><br></div><div>I have found the equivalent log line on my WSL Ubuntu. I was hoping I could find out more about where its coming from; ie which process / service prints this. But journalctl does not tell me much about the origin. </div><div><br></div><div><i><font face="monospace">journalctl -b --grep "Creating login session for velle" -o verbose<br>Wed 2023-11-29 18:41:19.982271 CET [s=d318bdab5d1f4ad7a48a947e6fff4a01;i=2d53;b=c8682ff139cf40da8326fd63d7c34d7c;m=1649><br> _TRANSPORT=kernel<br> _MACHINE_ID=967980c77d4743298ceaeb5d512bf388<br> _HOSTNAME=ELCON45223<br> PRIORITY=6<br> SYSLOG_FACILITY=1<br> MESSAGE=WSL (2): Creating login session for velle<br> _BOOT_ID=c8682ff139cf40da8326fd63d7c34d7c<br> _SOURCE_MONOTONIC_TIMESTAMP=23368229</font></i><br></div><div><br></div><div>Most log entries in journalctl has a _PID field, but some don't, and this one does not. Why? What does it tell, that a log entry has no _PID? As far as I know ever process has an PID, even systemd itself has a PID (which is always 1). Or am I wrong about that? I see now reason why those PIDs are not saved together with the log entries. </div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">According to _TRANSPORT the message went through the kernel log (dmesg), i.e. it was either kernel-generated (no PID) or it was written by the process to /dev/kmsg (PID information not preserved) rather than being sent the usual way through syslog. There might have been a PID but journald had no way to obtain it.</div><div dir="auto"><br></div><div dir="auto">That aside, another thing about WSL2 is that the entire VM actually boots a "system distro" first and the user-facing Ubuntu distro is started as a container. So there are several processes that run within the VM but exist outside of the container's PID namespace and therefore don't have PIDs from the Ubuntu container's PoV; only the "host" namespace has PIDs for them.</div><div dir="auto"><br></div><div dir="auto">(Consider how a container's "PID 1" looks from outside the container...)</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 27, 2023 at 10:37 AM Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com" target="_blank" rel="noreferrer">arvidjaar@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Nov 27, 2023 at 1:06 AM Thomas Larsen Wessel <<a href="mailto:mrvelle@gmail.com" target="_blank" rel="noreferrer">mrvelle@gmail.com</a>> wrote:<br> >><br> >> WSL does not use systemd by default.<br> ><br> ><br> > According to this article, it systemd has been default on WSL Ubuntu since june 2023. <a href="https://learn.microsoft.com/en-us/windows/wsl/systemd" rel="noreferrer noreferrer" target="_blank">https://learn.microsoft.com/en-us/windows/wsl/systemd</a><br> ><br> > "Systemd is now the default for the current version of Ubuntu that will be installed using the wsl --install command default."<br> ><br> > Also when I look in the /var/log/auth.log, there are many lines with systemd, e.g.:<br> ><br> > Nov 25 22:30:14 ELCON45223 systemd-logind[155]: New session 6 of user velle.<br> > Nov 25 22:30:14 ELCON45223 systemd: pam_unix(systemd-user:session): session opened for user velle(uid=1000) by (uid=0)<br> ><br> > Could someone please help me understand exactly which part creates this XDG_RUNTIME_DIR folder?<br> <br> /run/user/$UID for the "console" session (the one you get when<br> starting a WSL instance) is created by WSL before systemd. Adding "ls<br> -l /run/user" to user-runtime-dir@1000.service ExecStartPre:<br> <br> Nov 27 12:34:22 tumbleweed unknown: WSL (2) ERROR:<br> WaitForBootProcess:3237: /sbin/init failed to start within 10000<br> Nov 27 12:34:22 tumbleweed unknown: ms<br> Nov 27 12:34:22 tumbleweed unknown: WSL (2): Creating login session for andrei<br> ...<br> Nov 27 12:34:22 tumbleweed systemd[1]: Created slice User Slice of UID 1000.<br> Nov 27 12:34:22 tumbleweed systemd[1]: Starting User Runtime Directory<br> /run/user/1000...<br> Nov 27 12:34:22 tumbleweed ls[520]: total 0<br> Nov 27 12:34:22 tumbleweed ls[520]: drwxr-xr-x 4 andrei users 120 Nov<br> 27 12:34 1000<br> Nov 27 12:34:22 tumbleweed systemd-logind[160]: New session 11 of user andrei.<br> Nov 27 12:34:22 tumbleweed systemd[1]: Finished User Runtime Directory<br> /run/user/1000.<br> <br> So logind invokes user-runtime-dir@1000.service, but it sees the<br> existing directory and does nothing. I would suggest asking this<br> question on WSL support channels.<br> <br> > Is it part of the systemd repo or not? And if the answer is (or may be) different between Ubuntu and WSL Ubuntu, I would be happy if you share what you know about any any of those cases :) Right now, I barely know where to report this issue.<br> ><br> ><br> > On Sun, Nov 26, 2023 at 10:07 AM Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com" target="_blank" rel="noreferrer">arvidjaar@gmail.com</a>> wrote:<br> >><br> >> On 26.11.2023 02:39, Thomas Larsen Wessel wrote:<br> >> > I set up WSL on Windows 10 and created an instance from the default Ubuntu<br> >> > 22.04 image.<br> >> ><br> >> > I ran some (non-GUI) software that somehow relies on Qt, and apparently Qt<br> >> > does some checks on the XDG environment, so I got the following.<br> >> ><br> >> > *Warning: QStandardPaths: wrong permissions on runtime directory<br> >> > /run/user/1000/, 0755 instead of 0700*<br> >> ><br> >> > And yes, all the user folders are set to 755, including much of their<br> >> > content, which violates the XDG Base Directory Specification. (screenshot:<br> >> > <a href="https://i.imgur.com/ISn3ebh.png" rel="noreferrer noreferrer" target="_blank">https://i.imgur.com/ISn3ebh.png</a>).<br> >> ><br> >> > As far as I can understand, its some part of systemd, that creates this<br> >> > folder. So is this an issue with systemd?<br> >> ><br> >><br> >> WSL does not use systemd by default.<br> >><br> >> > The validate_runtime_directory in pam_systemd already does a number of<br> >> > checks on XDG_RUNTIME_DIR. How about also checking if the permissions are<br> >> > correct/valid?<br> >> ><br> >> > Sincerely, Thomas<br> >> ><br> >><br> </blockquote></div> </blockquote></div></div></div>