Systemd Linger

(coker.com.au)

31 points | by edward 3 hours ago

5 comments

  • walrus01 27 minutes ago
    Default Debian Trixie out of the box configuration without changing any systemd config file allows gnu screen to work as it always has. There would have been great uproar and screeching if basic 'screen' detach and resume functionality had broken anywhere between Debian v11, v12 and v13, and it has not.

    I'm assuming this is same for tmux but hasn't tested it.

    Is there some major distro out there that has the config flag set the opposite of this by default?

    • mike_hock 6 minutes ago
      > Default Debian Trixie out of the box configuration without changing any systemd config file allows gnu screen to work as it always has.

      As mentioned in the second sentence of TFA. Debian enables linger by default.

  • shevy-java 2 minutes ago
    Systemd is simply too complex.
    • saturn_vk 0 minutes ago
      Which part? Just saying systemd is like saying a distribution is too complex
  • graemep 1 hour ago
    This is why i dislike systemd. Things not working the way I expect means I have to do more work to figure something out.
    • Hendrikto 1 hour ago
      In my experience, systemd is much better documented, way more consistent, and way more reliable than what came before.
      • lucideer 1 hour ago
        I guess it depends on your source of info but I've found what came before was pretty comprehensively & accessibly documented, at least as well as systemd, which - while well documented - suffers from sprawl & overwhelm of the docs. There's just SO MUCH to grok in comparison.
        • BirAdam 50 minutes ago
          I never found systemd difficult, but I do find prior solutions to be simpler. An init script is easy, and the order is also easy. If people are accustomed to UNIX systems, the sysvinit is better. For people who never experienced those systems, systemd is their friend. No need to use UNIX tools when Systemd ships with batteries included.
        • m0llusk 54 minutes ago
          Absolutely not the case. Even relatively simple real world uses involved collections of shell scripts to carefully mount or initialize services in just the right order and would often fail with weird and infrequent timing glitches. With systemd that all becomes explicit, so of course it is awkwardly verbose. That is the whole point and a huge upgrade.
      • po1nt 1 hour ago
        Maybe, but the scale of systemd features is humongous. It better be well documented. You don't need a user manual for hammer, you do need one for hydraulic press.
        • nubinetwork 1 hour ago
          > hydraulic press

          What is there to know? It goes up and down, and don't stick your arm inside...

    • Someone 10 minutes ago
      > This is why i dislike systemd. Things not working the way I expect means I have to do more work to figure something out.

      Even if the change is a genuine improvement?

    • dietr1ch 28 minutes ago
      > Things not working the way I expect means I have to do more work to figure something out.

      Sound like you don't like computers to begin with

    • ChocolateGod 1 hour ago
      The fault lies in the distribution for it's default configuration, not systemd.

      The article even mentions that distros ship with it turned off

    • qweqwe14 47 minutes ago
      "The way you expect" is probably inconsistent and, upon closer inspection, completely broken.

      There is a reason why systemd became the default and other niche init systems have faded into obscurity.

      Sure, it may be more complex than your pile of shell scripts, but that's because it does the same things better, and has a lot more functionality that you will need at some point, and good luck replicating that by hacking shell scripts.

  • benj111 37 minutes ago
    I'm presumably missing something here. Why does tmux et al not work? Remotely? Ie you're logged in locally and remotely to the same machine, log out locally which kills everything running remotely, but then why would you log in twice like that?

    And that being the case can systemd not just only close everything when your logins reach 0?

    • tux3 32 minutes ago
      You can detach from screen/tmux, leave it running in the background, and log back in later to the same screen/tmux like you left it.

      Except systemd can kill it when you log out, so you come back to nothing.

      • benj111 17 minutes ago
        Ah ok. Seems like the log out metaphor is kind of broken then?

        It seems to me if you want persistence between logouts, the processes should belong to a different group/user.

        (I'm spitballing hypotheticalshere, not saying anyone/thing in particular is wrong)

  • iluvcommunism 43 minutes ago
    [dead]