Post #1150034
2026-04-14 20:23 UTC
Replies (5)
-
@mexicancartel@lemmy.dbzer0.com 2026-04-14 20:30
I hate thoose timeouts. If only there was a way to manually trigger that timeout on shutdown tty, say Ctrl-C or something which can kill it
-
@Archr@lemmy.world 2026-04-15 01:12
If you are having those issues with booting maybe it is because you configured your network share incorrectly? If you are waiting on shutdown timeouts for something then just go edit the timeout. systemctl edit . Typically when I crawl through journald it is to diagnose a problem with a specific application. Actually, the fact that those logs are easily accessible in a centralized place with easy to understand commands to access them is a reason why systemd (or more specifically systemd-journald) is so great. The only times that I have had major issues like that was either because (A) I misconfigured something or (B) a package came misconfigured.
-
@KernelTale@programming.dev 2026-04-15 06:00
My system once refused to boot, because I deleted a partition and didn’t remove it from fstab. Thankfully it was an easy and fast fix but I would expect it to just boot and give an error.
-
@Jesus_666@lemmy.world 2026-04-20 13:19
I have. Never had your machine just sit there and refuse to boot because a network share is down? Or because the wifi isn’t connected yet? I absolutely have. The solution wasn’t found in the init system, though, but by giving my NFS mounts the nofail option in /etc/fstab. Filesystem handling isn’t init’s job. Overall I haven’t had significantly more or less issues with systemd over OpenRC. I’m not a particularly big fan of their approach to things but their init system is perfectly serviceable.
-
@Wolf314159@startrek.website 2026-04-15 17:36
Ever really destroyed your server because the it needed were available? I have. It was so much worse than a boot process that froze. If Systemd was pausing due to a network share being down, it’s only because I (or you) told it to do exactly that. There are lots of good reasons to delay the boot process until all drives the system expects to be there are actually there or the network is up. Cleaning up the mess that happens when the system does not check these kinds of things at boot is so much worse. It’s never really some nebulous thing. Like it or not, intentional or not, the machine is doing exactly what you asked it to do and a delayed boot or a boot halted until you can solve the real problem is almost always better (or at least safer) than the alternatives. I’ve experienced all the things you’ve mentioned, dealt with each of those issues, and it was so much more of a hassle to diagnose before Systemd.