systemd 255 has been released, and it contains one particular new feature I want to highlight.
A new component “systemd-bsod” has been added to show logged error messages full-screen if they have a “LOG_EMERG” log level. This is intended as a tool for displaying emergency log messages full-screen on boot failures. Yes, BSOD in this case short for “Blue Screen of Death”. This was worked on as part of Outreachy 2023. The systemd-bsod will also display a QR code for getting more information on the error causing the boot failure.
↫ Michael Larabel at Phoronix
I like this. Operating systems usually have excellent logging capabilities, but getting to these logs and making sense of them isn’t always easy, especially if you’re not elbow-deep in the weeds of how your operating system of choice works. Giving a useful error screen when things really hit a brick wall at 200 km/h is a good thing, and will make at least some troubleshooting easier.
Usually the problem is shown in a log entry a few lines above though, I assume it will still be possible to view the log entries immediately before the emergency log details, without having to dig into the log file from storage media?
I’ll stick with “runit” since it boots much faster on my systems. But good to see they are making progress.
Same, I’ve never had runit hang up or freeze but (especially in Ubuntu based distros) I’ve had systemd hang at a process for sometimes several minutes. For all the bluster about it being so much faster to boot than any other init, it seems at least lately that it’s the slowest of all of them.
In my recent experience, sysvinit in Slackware, runit in Void, and OpenRC in Alpine are all booted within a few seconds, maybe ten at most, whereas systemd in Pop_OS! and Ubuntu take about a minute at times, and Bunsenlabs Linux (Debian based) and Fedora are usually about half that, though I’ve had shutdown hangs in systemd on Fedora too. It could be hardware related, but I routinely test all of the above distros as well as Haiku and OpenBSD snapshots on the same system (both booting very quickly, especially Haiku), so if it’s hardware related it’s still a systemd bug.
Morgan,
I haven’t managed to isolate the problem yet, but sometimes I experience hung shutdowns under systemd as well.
For my server distro I wrote my own init system similar to runit. It follows the “keep it simple, stupid” philosophy!
Systemd actually waits for services to die off on their on accord, I think the default is to wait sometime between 1 and 3 minutes, then it starts to kill it off hard. Comparing completely different init systems on different distros on different hardware/vm setups isn’t exactly apples to apples. Systemd is the only one that *can* effectively manage disparate services of all reliability levels across a wide array of hardware. This is why its pretty much taken over. If you have much lower requirements for an init, then the others are fine, if a bit more cumbersome to configure, imho. Systemd can be configured to be a super fast and safe start up, but the services have to be configured correctly. I have no idea how to parallelize the other init systems, if thats even possible. They may also just be cheating, not waiting for a service/socket to be come available before starting a required service just assuming it will be available. before its needed. Which would work maybe 99% of the time.
Bill Shooter of Bul,
While I hated sysvinit in particular, many init systems can and do work reliably as reliably as systemd though. Init systems aren’t really rocket science.
I wish systemd would have embraced the unix philosophy of doing one thing well, rather than becoming a kitchen sink solution. Oh well.
I agree with Alfman, i too have had serious hangs and crashes with systemd. runit is just so much faster on any distro i have tried from fedora, debian, devuan, voidlinux and many more. I understand why he would write his own init, he is competent enough to do so. Will it work for everyone? NO, but it works for him. That is the whole point. I never said that everyone should switch to runit, as that was never my point. I said it booted faster FOR ME on all my systems. I usually build most of my binaries from source, even though it is rather time consuming. I do not expect an average user to do so, nor do i demand that they comply with my preferences in other regards, i just demand that open source projects stay open and cater to it’s users, and not to mega-corps that might roll out the dimes when they want something done.
Not really worth going through the standard systemd argument again, but its the cgroups hierarchy that gives systemd its powers and basically requires it to do what some people consider to be a unix philosophy violation. Weather or not it does is like of like arguing about hotdogs and sandwiches.
Bill Shooter of Bul,
Well, obviously we won’t all agree but sometimes simpler really is better. I was using cgroups before systemd and systemd actually broke my cgroup containers, so it wasn’t all good 🙁
I wish them the best, but systemd has become an entagled mess. Like it or not, Terry Davies was right: https://www.youtube.com/watch?v=k0qmkQGqpM8 Complexity does not give you genius status, simplicity does.
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
― Antoine de Saint-Exupéry, Airman’s Odyssey
good lord. That is not how it works bill.