Because of the ubiquity, nay, monopoly of systemd I always assumed it was miles ahead of other init systems. Nope. I’ve been using a non-systemd environment for a while and must say I’m surprised by how little breaks, i.e., next to nothing. Moreover, boot and shutdown times are faster, and more of that good stuff. I suggest trying it out.

https://nosystemd.org/.

  • greyscale@lemmy.grey.oooEnglish
    16·
    1 day ago

    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? Or because its waiting on some nebulous thing until timeout…

    Never had to crawl through journalctl to diagnose things and wanted to claw your own eyes out in frustration?

    You are a fortunate person.

    • Wolf314159@startrek.website
      2·
      4 hours ago

      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.

    • Archr@lemmy.world
      12·
      20 hours ago

      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 <stuck thing>.

      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.

        • Archr@lemmy.world
          1·
          7 hours ago

          Strange I guess I am not aware of any distros that come with network drives pre-configured. But either way that would be a configuration error on the distro’s side then. Waiting for a network share to be available is actually a feature to many.

          Say for instance you had critical data on the network share then you might not want to boot if that is not available. And if you don’t then you might mark the share as nobootwait.

          Without knowing what the configuration on this specific drive you are having trouble with I really could not say what is wrong.

    • KernelTale@programming.devEnglish
      3·
      16 hours ago

      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.

      • flying_sheep@lemmy.ml
        3·
        15 hours ago

        Right, that happened to me too.

        And it’s a problem 100% unrelated to systemd, so I wouldn’t count it here.

    • mexicancartel@lemmy.dbzer0.comEnglish
      7·
      1 day ago

      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