Re: [systemd-devel] [help] Benchmarking software shows degraded performance
On 11/29/23 8:09 PM, nayabbasha.sa...@microchip.com wrote: One of the benchmark case is, where it simply opens graphical window on LCD screen and then simply closes it. For this case, the egt-benchmark shows 9 iterations/sec for busybox init. And it's only 5 iterations/sec for systemd init. Have you run perf or some other whole-system profiler on the system to see what time is spent in what process and how the systemd case differs from the busybox case? -- Christian
[systemd-devel] [help] Benchmarking software shows degraded performance
Hi all, We have decided to replace buysbox init with systemd in our development boards Buildroot images. One of the boards - https://www.microchip.com/en-us/development-tool/atsama5d27-som1-ek1 While we notice the reduction in boot time as well as the systemd features useful (ex: systemd-networkd), we notice the degraded performance when we run bench-marking software. Benchmarking software uri - https://github.com/linux4sam/egt-benchmark. One of the benchmark case is, where it simply opens graphical window on LCD screen and then simply closes it. For this case, the egt-benchmark shows 9 iterations/sec for busybox init. And it's only 5 iterations/sec for systemd init. We have gone through some of the techniques mentioned in the bootlin's debugging slides (https://bootlin.com/doc/training/debugging/debugging-slides.pdf) to optimize the system performance. Didn't help much. Note that all the development boards we use are single core SoCs. Any pointers that would lead to narrow down the issue would be grateful here. Thanks in advance. -- Thanks, Nayab
Re: [systemd-devel] WSL Ubuntu creates XDG_RUNTIME_DIR with incorrect permissions
On Wed, Nov 29, 2023, 20:59 Thomas Larsen Wessel wrote: > Thanks both of you! :) > > I have taken some time to digest your answers. And in particular I have > tried to investigate this line closer: > > *Nov 27 12:34:22 tumbleweed unknown: WSL (2): Creating login session for > andrei* > > 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. > > > > > > > > > > > *journalctl -b --grep "Creating login session for velle" -o verboseWed > 2023-11-29 18:41:19.982271 CET > [s=d318bdab5d1f4ad7a48a947e6fff4a01;i=2d53;b=c8682ff139cf40da8326fd63d7c34d7c;m=1649> > _TRANSPORT=kernel_MACHINE_ID=967980c77d4743298ceaeb5d512bf388 > _HOSTNAME=ELCON45223PRIORITY=6SYSLOG_FACILITY=1MESSAGE=WSL (2): > Creating login session for velle > _BOOT_ID=c8682ff139cf40da8326fd63d7c34d7c > _SOURCE_MONOTONIC_TIMESTAMP=23368229* > > 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. > 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. 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. (Consider how a container's "PID 1" looks from outside the container...) > > > On Mon, Nov 27, 2023 at 10:37 AM Andrei Borzenkov > wrote: > >> On Mon, Nov 27, 2023 at 1:06 AM Thomas Larsen Wessel >> wrote: >> >> >> >> WSL does not use systemd by default. >> > >> > >> > According to this article, it systemd has been default on WSL Ubuntu >> since june 2023. https://learn.microsoft.com/en-us/windows/wsl/systemd >> > >> > "Systemd is now the default for the current version of Ubuntu that will >> be installed using the wsl --install command default." >> > >> > Also when I look in the /var/log/auth.log, there are many lines with >> systemd, e.g.: >> > >> > Nov 25 22:30:14 ELCON45223 systemd-logind[155]: New session 6 of user >> velle. >> > Nov 25 22:30:14 ELCON45223 systemd: pam_unix(systemd-user:session): >> session opened for user velle(uid=1000) by (uid=0) >> > >> > Could someone please help me understand exactly which part creates this >> XDG_RUNTIME_DIR folder? >> >> /run/user/$UID for the "console" session (the one you get when >> starting a WSL instance) is created by WSL before systemd. Adding "ls >> -l /run/user" to user-runtime-dir@1000.service ExecStartPre: >> >> Nov 27 12:34:22 tumbleweed unknown: WSL (2) ERROR: >> WaitForBootProcess:3237: /sbin/init failed to start within 1 >> Nov 27 12:34:22 tumbleweed unknown: ms >> Nov 27 12:34:22 tumbleweed unknown: WSL (2): Creating login session for >> andrei >> ... >> Nov 27 12:34:22 tumbleweed systemd[1]: Created slice User Slice of UID >> 1000. >> Nov 27 12:34:22 tumbleweed systemd[1]: Starting User Runtime Directory >> /run/user/1000... >> Nov 27 12:34:22 tumbleweed ls[520]: total 0 >> Nov 27 12:34:22 tumbleweed ls[520]: drwxr-xr-x 4 andrei users 120 Nov >> 27 12:34 1000 >> Nov 27 12:34:22 tumbleweed systemd-logind[160]: New session 11 of user >> andrei. >> Nov 27 12:34:22 tumbleweed systemd[1]: Finished User Runtime Directory >> /run/user/1000. >> >> So logind invokes user-runtime-dir@1000.service, but it sees the >> existing directory and does nothing. I would suggest asking this >> question on WSL support channels. >> >> > 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. >> > >> > >> > On Sun, Nov 26, 2023 at 10:07 AM Andrei Borzenkov >> wrote: >> >> >> >> On 26.11.2023 02:39, Thomas Larsen Wessel wrote: >> >> > I set up WSL on Windows 10 and created an instance from the default >> Ubuntu >> >> > 22.04 image. >> >> > >> >> > I ran some (non-GUI) software that somehow relies on Qt, and >> apparently Qt >> >> > does some checks on the XDG environment, so I got the following. >> >> > >> >> > *Warning: QStandardPaths: wrong permissions on runtime directory >> >> > /run/user/1000/, 0755 instead of 0700* >> >> > >> >> > And yes, all the user folders are set
Re: [systemd-devel] WSL Ubuntu creates XDG_RUNTIME_DIR with incorrect permissions
Thanks both of you! :) I have taken some time to digest your answers. And in particular I have tried to investigate this line closer: *Nov 27 12:34:22 tumbleweed unknown: WSL (2): Creating login session for andrei* 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. *journalctl -b --grep "Creating login session for velle" -o verboseWed 2023-11-29 18:41:19.982271 CET [s=d318bdab5d1f4ad7a48a947e6fff4a01;i=2d53;b=c8682ff139cf40da8326fd63d7c34d7c;m=1649> _TRANSPORT=kernel_MACHINE_ID=967980c77d4743298ceaeb5d512bf388 _HOSTNAME=ELCON45223PRIORITY=6SYSLOG_FACILITY=1MESSAGE=WSL (2): Creating login session for velle _BOOT_ID=c8682ff139cf40da8326fd63d7c34d7c _SOURCE_MONOTONIC_TIMESTAMP=23368229* 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. On Mon, Nov 27, 2023 at 10:37 AM Andrei Borzenkov wrote: > On Mon, Nov 27, 2023 at 1:06 AM Thomas Larsen Wessel > wrote: > >> > >> WSL does not use systemd by default. > > > > > > According to this article, it systemd has been default on WSL Ubuntu > since june 2023. https://learn.microsoft.com/en-us/windows/wsl/systemd > > > > "Systemd is now the default for the current version of Ubuntu that will > be installed using the wsl --install command default." > > > > Also when I look in the /var/log/auth.log, there are many lines with > systemd, e.g.: > > > > Nov 25 22:30:14 ELCON45223 systemd-logind[155]: New session 6 of user > velle. > > Nov 25 22:30:14 ELCON45223 systemd: pam_unix(systemd-user:session): > session opened for user velle(uid=1000) by (uid=0) > > > > Could someone please help me understand exactly which part creates this > XDG_RUNTIME_DIR folder? > > /run/user/$UID for the "console" session (the one you get when > starting a WSL instance) is created by WSL before systemd. Adding "ls > -l /run/user" to user-runtime-dir@1000.service ExecStartPre: > > Nov 27 12:34:22 tumbleweed unknown: WSL (2) ERROR: > WaitForBootProcess:3237: /sbin/init failed to start within 1 > Nov 27 12:34:22 tumbleweed unknown: ms > Nov 27 12:34:22 tumbleweed unknown: WSL (2): Creating login session for > andrei > ... > Nov 27 12:34:22 tumbleweed systemd[1]: Created slice User Slice of UID > 1000. > Nov 27 12:34:22 tumbleweed systemd[1]: Starting User Runtime Directory > /run/user/1000... > Nov 27 12:34:22 tumbleweed ls[520]: total 0 > Nov 27 12:34:22 tumbleweed ls[520]: drwxr-xr-x 4 andrei users 120 Nov > 27 12:34 1000 > Nov 27 12:34:22 tumbleweed systemd-logind[160]: New session 11 of user > andrei. > Nov 27 12:34:22 tumbleweed systemd[1]: Finished User Runtime Directory > /run/user/1000. > > So logind invokes user-runtime-dir@1000.service, but it sees the > existing directory and does nothing. I would suggest asking this > question on WSL support channels. > > > 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. > > > > > > On Sun, Nov 26, 2023 at 10:07 AM Andrei Borzenkov > wrote: > >> > >> On 26.11.2023 02:39, Thomas Larsen Wessel wrote: > >> > I set up WSL on Windows 10 and created an instance from the default > Ubuntu > >> > 22.04 image. > >> > > >> > I ran some (non-GUI) software that somehow relies on Qt, and > apparently Qt > >> > does some checks on the XDG environment, so I got the following. > >> > > >> > *Warning: QStandardPaths: wrong permissions on runtime directory > >> > /run/user/1000/, 0755 instead of 0700* > >> > > >> > And yes, all the user folders are set to 755, including much of their > >> > content, which violates the XDG Base Directory Specification. > (screenshot: > >> > https://i.imgur.com/ISn3ebh.png). > >> > > >> > As far as I can understand, its some part of systemd, that creates > this > >> > folder. So is this an issue with systemd? > >> > > >> > >> WSL does not use systemd by default. > >> > >> > The validate_runtime_directory in pam_systemd already does a number of > >> > checks on XDG_RUNTIME_DIR. How about also checking if the permissions > are > >> > correct/valid? > >> > > >> > Sincerely, Thomas > >> > > >> >
Re: [systemd-devel] How to properly wait for udev?
On Mo, 27.11.23 21:32, Richard Weinberger (richard.weinber...@gmail.com) wrote: > On Mon, Nov 27, 2023 at 9:29 AM Lennart Poettering > wrote: > > If they conceptually should be considered block device equivalents, we > > might want to extend the udev logic to such UBI devices too. Patches > > welcome. > > Why doesn't udev flock() every device it is probing? > Or asked differently, why is this feature opt-in instead of opt-out? Some software really doesn't like it if we take BSD locks on their devices, hence we don't take it blanket everywhere. And what's more important even: for various devices it simply isn't safe to just willy-nilly even open them (tape drivers and things, which might start to pull in a tape if we do). For others we might not be able to even open thing at all with the wrong flags (for example, because they are output only). Bock devices have relatively well defined semantics, there it's generally safe to do this, hence we do. Hence, it might be safe for UBI, but for the general case it might not be. That said, would BSD locking even address your issue? If you devices are exclusive access things and we first open() them and then flock() them, then that's not atomic. So if your test cases open the devices, then flock() them you might still get into conflict udev because it just open()ed the device, but didn#t get to call flock() yet. Doesn't UBI have something like O_EXCL-behaviour that grants true exclusive access? Lennart -- Lennart Poettering, Berlin
