Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Systemd is simply too complex.
    by shevy-java
  • Which part? Just saying systemd is like saying a distribution is too complex
    by saturn_vk
  • The Linux kernel is simply too complex.
    by surajrmal
  • But how much of it is inherent complexity?
    by dietr1ch
  • While perhaps maybe sometimes useful on desktops, all this logind crap absolutely must be removed from servers.

    Personally me I fail to see any scenario where this is genuinely useful.

    by egorfine
  • 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?

    by benj111
  • LP knows better what should work for you and what not.
    by egorfine
  • 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.

    by tux3
  • 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.

    by kmbfjr
  • This is hideously annoying functionality for anyone heavily using detached tmux and screen sessions. Massively annoyed and such an unfriendly kdea.
    by unixhero
  • This is why i dislike systemd. Things not working the way I expect means I have to do more work to figure something out.
    by graemep
  • The fault lies in the distribution for it's default configuration, not systemd.

    The article even mentions that distros ship with it turned off

    by ChocolateGod
  • I, for one, appreciate the honesty. I wish more systemd haters would admit this is why they dislike it. We could finally throw away the tired arguments that have been disproven in the past ten years
    by halJordan
  • "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.

    by qweqwe14
  • > Things not working the way I expect means I have to do more work to figure something out.

    You must love SELinux

    by nurettin
  • > 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?

    by Someone
  • 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.
    by mike_hock
  • > Things not working the way I expect means I have to do more work to figure something out.

    I dunno, "things not working the way I expect" is very subjective.

    I personally think it makes more sense that processes do not outlive the parent from which they come (in this case processes spawned from a user shouldn't outlive that user) unless you explicitly go through something which outlive the parent (process manager in this case (e.g. running via systemd-run)).

    Though I am also strongly of the opinion of just because something is a feature, does not mean it is good to keep around, e.g SUID/SGID (which has a similar "I get more than the parent" problem).

    Though I guess different people can have different opinions/values on this.

    by NekkoDroid
  • In my experience, systemd is much better documented, way more consistent, and way more reliable than what came before.
    by Hendrikto
  • 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?

    by walrus01
  • > 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)

    by yjftsjthsd-h
  • > 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.

    by mike_hock
  • Having user processes killed upon log out seems pretty reasonable to me, and its a configurable option if you don't like it. I don't get the fuss here.

    I think it's just popular to dislike systemd, some sort of echo chamber effect or something.

    by chlorion