Systemd Linger(etbe.coker.com.au)
43 pointsby edward6 hours ago6 comments
  • walrus012 hours 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?

    • yjftsjthsd-han hour ago
      > Is there some major distro out there that has the config flag set the opposite of this by default?

      It bit me on pop os (the Ubuntu derivative)

    • mike_hock2 hours 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.

  • graemep3 hours 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.
    • Hendrikto3 hours ago
      In my experience, systemd is much better documented, way more consistent, and way more reliable than what came before.
      • lucideer3 hours 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.
        • BirAdam3 hours 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.
          • dietr1ch2 hours ago
            Yeah, init scripts are simple, but things get tricky outside of the happy path. Think of service upgrades/restarts. Once you care about dependencies, then you are back to a graph like systemd's.
            • iririririran hour ago
              talking "outside happy path" in defense of systemd is wild. because that's it's Achilles heel.

              systemd is awfully documented (volume is not quality), things are still changing and haven't even caught up in functionality with any init hack.

              the only saving grace of systemd is that it almost makes it easier to use namespace and other sandbox (but only because those are newer and init systems also didn't have their solutions up yet)

              systemd only purpose is to mimic windows administration in linux. sorry of anyone who fails to see this

        • 7bitan hour ago
          No way. I was easily able to create Systemd units from 0-knowledge, where the init system remains a big black box riddled with question marks for a very long time. Very little was documented.
        • m0llusk3 hours 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.
          • shevy-java2 hours ago
            I never used shell scripts for that. Ruby worked much better and easier. No glitches either.

            I also fail to see how verbosity is a "huge upgrade".

      • po1nt3 hours 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.
        • nubinetwork3 hours ago
          > hydraulic press

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

          • po1nt2 minutes ago
            Until it breaks, reports error, leaks, makes weird sound, needs a maintenance or even if you want to move it. You need to know how heavy it is, where are mounting points, where is the center of gravity, what needs to be affixed etc. What is the power it draws for the pump, what is the peak power and how long is the peak, what is the power factor? Does it have a safety certification, what kind of training operator needs, are safety elements up to date to modern standard? What kind of fire extinguisher do you need? What is the toxicity of all the materials under normal and extreme conditions? What kind of peak force is applied to floor and how is it distributed?
        • 7bitan hour ago
          The scale is humongous? Syszemd is not one big thing. It's a collection of small things, each meticoulsouy documented and you can pick and choose.

          If you still think there is only one Systemd, maybe learn about the tool instead of just talking others after their mouth.

          • iririririran hour ago
            that's wrong in the sense it won't be useful for anything unless you have a dozen of those small things setup in the very specific way the author envisioned you set them up.

            you seem to be repeating all the marketing, while mentioning in other comments you never understood any init system. i don't think you're the authority to be adding so many comments here.

      • dosisking2 hours ago
        Well, in my experience, systemd has much worse documentation, is very inconsistent (or you could say it is constistantly brain-dead), and extremely unreliable and unpredictable, since it often hangs when shutting down and rebooting.
        • bombcaran hour ago
          systemd is like the registry. If you drink the koolaid and fully admit and adopt the decisions made, you’ll do ok, perhaps even good.

          If you have 20+ years of experience, you’ll will NEVER get it to work the way you expect, might as well install Gentoo.

      • shevy-java2 hours ago
        So, I disagree about your statement here, but let's for a moment assume it were correct - so let's not evaluate THAT particular statement, thus.

        You most likely refer to sysinit or something like that, right? Because to what else do you compare it to? Shell scripts?

        Shell scripts in general are crap. I don't understand why linux systems use them. When I transitioned to linux a long time ago, I wrote - and still write - pretty much all logic in ruby and .yml files. Literally my whole system is described via .yml files, ruby then just auto-expands all of this into what is meaningful. I also compile from source and manage the system via ruby as-is, so I don't even need systemd, nor shell scripts. But this is just one comment here and if you refer to shell scripts then I agree with you - shell scripts have always been horrible. I fail to see why we should like systemd merely because shell scripts are so awful. That makes no sense. I neither use systemd nor shell scripts (ok ok I bail ... I am currently using manjaro which uses systemd; I disabled most of the services, but the primary reason I was assimilated into systemd is mostly because the non-systemd linux distributions, kind of gave up for the most part or come with their own set of problems - slackware, void and so forth. And yeah, I was using and testing them for ages too, slackware I used for many, many years. It is still a great distribution but it is not really active anymore. No new .iso releases in years, sorry, that is dead. Even if Patrick still updates packages.)

        The other part is ... IF you referred to an alternative init system, then THAT comparison is flawed too, because sysvinit is mostly just an init system. Systemd is some giant thing that does 100000 things. So the comparison is, and ALWAYS has been, unfair. Not the same things are compared here.

        • eptcyka2 hours ago
          Systemd is not 1 giant thing that does 100000 things - it is a collection or 10000 services doing 10000 things, integrating amongst themselves where practical. You need not use networkd, logind, resolved or any other one piece of the system you dislike.
        • yjftsjthsd-han hour ago
          > You most likely refer to sysinit or something like that, right? Because to what else do you compare it to? Shell scripts?

          dinit is a good service manager that doesn't feel obligated to reinvent the kitchen sink

    • mike_hock2 hours ago
      It's one of those systemd features that are annoying and in the way when you're trying to accomplish a specific task but deal well with shitware. To be fair to systemd, these features can't usually be implemented without writing new rules for what you have to do to accomplish the legitimate tasks.
    • Someone2 hours 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?

      • dosisking2 hours ago
        How can the change be a genuine improvement, if it does something unexpected that needs to be figured out?
      • graemepan hour ago
        This is not a genuine improvement:

        > One of the features of systemd that is most controversial is the option to kill user processes when the user logs out. That initially killed screen/tmux/nohup processes too.

        Killing processes that the user clearly did not want killed is a regression.

        Reading the rest of article it seems that its fixed but made things a lot more complicated than "unless you deliberately start things so that they keep running when you logout they will be killed when you logout". Am I wrong?

    • ChocolateGod3 hours 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

      • yjftsjthsd-han hour ago
        The fault lies in the upstream defaulting the option on, so that distros have to
    • nurettin2 hours ago
      > Things not working the way I expect means I have to do more work to figure something out.

      You must love SELinux

    • qweqwe143 hours 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.

      • yjftsjthsd-h43 minutes ago
        > "The way you expect" is probably inconsistent and, upon closer inspection, completely broken.

        When I start a program, I want it to stay running. This is perfectly consistent and not broken.

      • graemep44 minutes ago
        You are framing this as the only choice being between systemd and shell scripts.
      • dosisking2 hours ago
        > There is a reason why systemd became the default and other niche init systems have faded into obscurity.

        Yes, it is part of the Embrace, Extend, Extinguish strategy

        • qweqwe14an hour ago
          No, it is part of the "I just want stuff to work" strategy
    • dietr1ch2 hours 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

      • dosisking2 hours ago
        He probably just doesn't like having to use poorly written software
  • benj1113 hours 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?

    • tux32 hours 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.

      • c-hendricks16 minutes ago
        What I don't get is why (on Arch) I have linger off yet have never had trouble with tmux/ zellij being killed.

        Edit: ah, this post clears it up. Mentions linger has nothing to do with screen muxers, and also brings KillUserProcesses to peoples attention.

        Damn systemd and its multiple levels of convenience.

      • benj1112 hours 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)

        • dietr1ch2 hours ago
          Think about user services in a multi-user setup

          Do you want user-level services, or a multi-tenant system-level service? - Who can tweak the service configuration? - How do you ensure there's no data leaks between users? - What about misbehaviour? Quotas, crashes

          I think lingering is great here

          • benj111an hour ago
            Off the top of my head. Have a group that doesn't die on logout. So you can have an email Daemon that responds with out of office. And you tmux session can keep running?

            I'm not necessarily talking about the Unix concept of a group. It seems to me you want some granularity between 'kill all processes' and 'keep all processes'

  • shevy-java2 hours ago
    Systemd is simply too complex.
    • dietr1ch2 hours ago
      But how much of it is inherent complexity?
      • tremon2 hours ago
        Only the pid 1 sigchild handling. Everything else is design choices.
      • dosisking2 hours ago
        About 0.1% is inherent complexity
    • saturn_vk2 hours ago
      Which part? Just saying systemd is like saying a distribution is too complex
      • agumonkey2 hours ago
        I may be wrong but he was probably hinting at systemd being a constellation of too many parts.
      • realusername2 hours ago
        As a user I can say that journald was a mistake, if you try to reinvent a database, you will reinvent it poorly and journald wasn't an exception.
  • kmbfjr2 hours ago
    I never had a problem with systemd init despite its quirky habits like just giving up if a mount is bad in fstab, and I rather like systemd-networkd over the other four or five ways of managing the network. Systemd-timesyncd isn’t bad either.

    But this, systemd-logind worrying about stuck processes in userspace is exactly the kind of scope creep that ends up justifying a lot of the hand wringing a decade ago. This thing bit me when it came out in a couple different ways and I am unapologetic in my dislike for it. So much so that it has caused me to drift away from Linux where I can. Even though it is a simple fix, I’ve become fatigued with userspace chaos.

    Time to re-evaluate what the bazaar has become. Systemd is a common complaint, but it isn’t the only contributor to the fatigue.

  • iluvcommunism3 hours ago
    [dead]