Since upgrading from Plasma 6.0 to Plasma 6.1 my journald.service takes a longtime to boot.
Since upgrading from Plasma 6.0 to Plasma 6.1 my journald.service takes a longtime to boot.
Since upgrading from Plasma 6.0 to Plasma 6.1 my journald.service takes a longtime to boot.
systemd-journald.service takes 7-8 seconds.
Even on a freshly installed system.
systemd-analyze:
Startup finished in 9.534s (firmware) + 6.112s (loader) + 3.281s (kernel) + 9.271s (userspace) = 28.200s
systemd-analyze critical-chain systemd-journald.service:
systemd-journald.service +7.853s └─systemd-journald.socket @428ms
systemd-analyze blame:
7.853s systemd-journald.service 2.152s systemd-modules-load.service 1.147s \x2esnapshots.mount 715ms NetworkManager.service 229ms dev-nvme1n1p2.device
how can I now further troubleshoot and maybe find a solution? has someone experienced same/similar? I can provide further info if needed, would appreciate very much if someone has an idea...
Edit: after working through it I came to the conclusion, that maybe Plasma isn‘t the issue here (since the „error“ happens way before graphical ui shows up), but more kernel related. Trying right now to get an older kernel running to see, if it confirms my assumption, but failed yet to do so…
I haven't tried to troubleshoot this, but I think the first thing I'd probably try is to see how long
sudo systemctl restart systemd-journald.servicetakes, whether it's specifically blocking at something on boot or whether it always takes a long time to come up.@tal@lemmy.today great hint, will try this, thanks!
@tal@lemmy.today so I was able to perform the test, and if I restart it manually it is fast (30-34ms), its just while booting where it takes that long
Interesting. I have no input but I'm curious of the cause.
considers
Might be either blocking waiting for something else to start up or waiting for something like drives to spin up, since I assume that it touches drives.
I bet that systemd has some kind of dependency analysis for time.
looks in man page
Yeah. Maybe try rebooting so that you run into the slow startup again, then running
systemd-analyze critical-chain systemd-journald.service. Looks like that shows how much time is spent showing what other systemd units were being blocked on.