Linux
Welcome to c/linux!
Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!
Rules:
-
Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.
-
Be respectful: Treat fellow community members with respect and courtesy.
-
Quality over quantity: Share informative and thought-provoking content.
-
No spam or self-promotion: Avoid excessive self-promotion or spamming.
-
No NSFW adult content
-
Follow general lemmy guidelines.
view the rest of the comments
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 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
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.@tal@lemmy.today Did exactly that before posting and posted the output:
systemd-analyze critical-chain systemd-journald.service:
systemd-journald.service +7.853s └─systemd-journald.socket @428ms