1. 6

    I like systemd. Whenever it comes up I tend to ignore the comments because of the haters, but know that not everyone hates it.

    Bona fides: professional Linux sysadmin. ~20 year Linux user (~16 as my only desktop OS). I don’t work for Red Hat.

    1. 4

      Not an unreasonable comment, but in this thread? “Hey tmux guy, get to work and do as the nice systemd people say.”

      1. 11

        I didn’t mean for my comment to read that way, my apologies for being unclear.

        The various distribution maintainers seem to agree that systemd is the future, at least for now, which ultimately means tmux will either not work as advertised or will require some modifications. It sounds like those will ether be part of a non-standard patch bringing in a dbus dependency that the distribution ships or some sort of wrapper around tmux that invokes systemd-run, also implemented as a non-standard distribution provided patch. It’s unfortunate that the systemd developers have burned all the goodwill that other people and projects were willing to give them. But the bridges were burned, the systemd folks were jackasses, and now everyone hates them regardless of the technical merits of systemd may have.

        In conclusion: don’t be a jackass. Also, empathy.

        1. 4

          That’s fair.

          1. [Comment removed by author]

            1. 6

              Apparently this feature is required because gnome fails to run correctly when leftover processes aren’t killed, and gnome is also incapable of not creating leftover processes. So anybody that reverts or disables it will break gnome.

              1. 3

                What I understood is that it’s not broken per se. It’s just that every time you log in again, there will be yet another ssh-agent or gpg-agent or gnome-shell-calendar-server spawned.

                Not sure what the big deal with that is, though.

                1. 3

                  Apparently “intelligent auto discovery” is sometimes not so smart, and finds processes that belong to other users, etc. or you get the situation where you add your ssh keys to one agent, but then ssh tries to use a different agent for auth.

                2. 2

                  So when can we expect this systemd change in OpenBSD as part of the gnome support?? :)

                  1. 2

                    Could you please provide more information about this? Some link, bug report, mail in the gnome mailing list? I would like to know more.

                    1. 12

                      So there’s this gnome bug report: https://bugs.freedesktop.org/show_bug.cgi?id=94508 and this systemd issue: https://github.com/systemd/systemd/issues/2900

                      Somebody changed gnome to use systemd sessions, but that fucked things up, so then systemd changed default to kill more processes, so now tmux needs to do something differently. Because gnome asked for something to happen and couldn’t handle the consequences.

                      (Gnome/dbus/whatever. Sorry, I can’t always tell the difference. Gnome breaks because dbus doesn’t exit? Either way, doesn’t sound like a problem systemd should solve, and sure as shit shouldn’t involve tmux.)

                      1. 3

                        And this is how a bug becomes a feature request…

            2. 2

              Edit: Misread TFA. Made silly comment. Deleted.

              1. 3

                It never was “I live as long as the box lives”. It was “I live as long as I’m not told to quit, or until the box shuts down”.

                And who tells tmux to quit? Why yes, the user (if not the admin). That is how tmux knows how long the user needs it; by the user telling it to quit when no longer needed. Now how does systemd help here again?

                This change isn’t about making a new way for the user to tell tmux to quit, it’s about making a new way for tmux to say it doesn’t want to be quit. We already have a way to do that. Don’t break that.

                1. 2

                  One of the purposes of screen and tmux is to stay there after the session is disconnected and to be available for re-attachment when the user reconnects. If it weren’t its purpose, it would not ignore SIGHUP.

                  1. 1

                    Huh? The proposed solution is for tmux to create a lingering scope, which also lives forever. It is exactly as “wasteful” as before. The only thing that changes is how many more hundreds of lines of code are necessary to achieve this effect.