Does anyone know where these 3 seconds come from?
Jul 04 21:10:08 weingeist-PC systemd[1]: Reached target Multi-User System.
Jul 04 21:10:11 weingeist-PC kernel: usbcore: registered new interface driver snd-usb-audio
systemd-analyze can help you answer that question.
Please edit your topic title to be clear and concise about the issue. See How to Post.
not for me
graphical.target @6.545s
└─plasmalogin.service @2.993s +3.550s
└─systemd-user-sessions.service @2.989s +3ms
└─network.target @2.988s
└─NetworkManager.service @2.877s +111ms
└─basic.target @2.876s
└─dbus-broker.service @2.803s +49ms
└─dbus.socket @2.796s +36us
└─sysinit.target @2.791s
└─systemd-update-utmp.service @2.753s +37ms
└─systemd-tmpfiles-setup.service @2.682s +67ms
└─local-fs.target @2.677s
└─home.mount @2.603s +73ms
└─systemd-fsck@dev-disk-by\x2duuid-2f172fb6\x2dcd94\x2d454a\x2d84b9\x2daa8abb386b63.service @1.859s +35ms
└─dev-disk-by\x2duuid-2f172fb6\x2dcd94\x2d454a\x2d84b9\x2daa8abb386b63.device
Edit
raphical.target @6.511s
└─plasmalogin.service @3.155s +3.355s
└─systemd-user-sessions.service @3.149s +4ms
└─network.target @3.148s
└─NetworkManager.service @3.059s +88ms
└─basic.target @3.058s
└─dbus-broker.service @3.017s +31ms
└─dbus.socket @3.015s +7us
└─sysinit.target @3.010s
└─systemd-vconsole-setup.service @1.885s +1.124s
└─systemd-journald.socket
└─system.slice
└─-.slice
The time elapsed between incidents?
What is the problem?
plasmalogin.service has 3 Seconds boot time. It didn’t use to be like that, and I can’t figure out why.
Congratulations on the new avatar.
I tend to forget that behind the avatars are real people - so by using the phpto from Team – Manjaro as avatar - I tell myself to remember the man or woman behind the username.
$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @12.430s
└─multi-user.target @12.430s
└─ollama.service @12.430s
└─network-online.target @12.428s
└─NetworkManager-wait-online.service @6.428s +5.999s
└─NetworkManager.service @5.636s +790ms
└─basic.target @5.635s
└─systemd-pcrphase-sysinit.service @5.588s +47ms
└─sysinit.target @5.561s
└─systemd-tpm2-setup.service @3.204s +2.356s
└─systemd-tpm2-setup-early.service @659ms +2.540s
└─tpm2.target @3.085s
└─dev-tpmrm0.device
On my workstation - which is using the plasma login manager - I don even have the service in the chain.
So I am thinking it is a coincidence and not something to be worried about.
It’s no coincidence; this has been going on for about two months.
It only happens on my desktop PC, though—I don’t have this issue on my laptop. Everything works fine, too. It’s just interesting.
I wonder if it could be waiting for the systemd-udev-settle.service to detect all hardware/devices?
systemd-udev-settle.service - Wait for all pending udev events to be handled
This Arch forum thread could provide the fix for it:
Specifically, this post:
The above will override the ExecStartPre=-udevadm settle --timeout=10 default setting in /usr/lib/systemd/system/plasmalogin.service:
❯ grep -i execstartpre /usr/lib/systemd/system/plasmalogin.service
ExecStartPre=-udevadm settle --timeout=10
3 Likes
@scotty65 you are the HERO and kokoko3k
graphical.target @2.001s
└─plasmalogin.service @2.001s
└─systemd-logind.service @1.782s +217ms
└─basic.target @1.760s
└─dbus-broker.service @1.735s +16ms
└─dbus.socket @1.733s +7us
└─sysinit.target @1.732s
└─systemd-update-utmp.service @1.703s +28ms
└─systemd-tmpfiles-setup.service @1.664s +38ms
└─local-fs.target @1.663s
└─mnt-Steam.mount @1.605s +57ms
└─dev-nvme0n1p1.device
And I’ve been searching so hard for the solution. That forum post was born of sheer desperation. Perhaps a temporary workaround should be created, since this affects the stable branch too—as I discovered on my laptop today.
2 Likes
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.