Systemd developer asks tmux to add systemd specific code

Salient comment: &quot;Or somebody could go find the actual problem @keszybz saw here - systemd&#x2F;systemd#3005 - which is: <i>In particular, for my gnome session, if I log out, without KillUserProcesses=yes I get some processes which are obviously mistakes. Even if I log in again, I&#x27;m much better starting those again cleanly.</i> fix that, and stop trying to make systemd break the world because somebody&#x27;s gnome session doesn&#x27;t currently exit cleanly.&quot;

Why is this upsetting to so many people? This seems to me like a simple request to add platform-specific code, and in the end there was a decision to take a different approach to solve the problem.<p>Seems to me like yet another systemd two minute hate. It&#x27;s getting quite tiresome to see.

A surprising and troubling comment in the github comments: &quot;Honestly, I don&#x27;t see why processes should be able to decide that they should run forever.&quot;<p>I actually let slip an f-bomb reading that. It shows a terrible understanding of longstanding unix philosophy, (and also straw-mans the argument).<p>Happily, it doesn&#x27;t seem that was from a systemd developer as far as I can tell from their website. Still, it&#x27;s a reminder that the userbase (and developer base) that engage with Unix&#x2F;Linux&#x2F;GNU is varied, and may not have grown up with the same sensibilities that people my age have about where the right line between user, system and sysadmin should lie.

Because a project should <i>never</i> have platform specific code.<p><pre><code> justin@t420:&#x2F;tmp$ git clone https:&#x2F;&#x2F;github.com&#x2F;tmux&#x2F;tmux.git justin@t420:&#x2F;tmp$ cd tmux justin@t420:&#x2F;tmp&#x2F;tmux$ wc -l osdep* 95 osdep-aix.c 88 osdep-cygwin.c 80 osdep-darwin.c 133 osdep-dragonfly.c 202 osdep-freebsd.c 41 osdep-hpux.c 98 osdep-linux.c 137 osdep-netbsd.c 157 osdep-openbsd.c 101 osdep-sunos.c 41 osdep-unknown.c 1173 total </code></pre> Apparently people have been trying to get tmux fixed for FIVE YEARS NOW<p><a href="http:&#x2F;&#x2F;tmux-users.narkive.com&#x2F;LXp72CHV&#x2F;pam-support-in-tmux" rel="nofollow">http:&#x2F;&#x2F;tmux-users.narkive.com&#x2F;LXp72CHV&#x2F;pam-support-in-tmux</a>

Cast your mind back to when SIGHUP first started getting sent to processes on logout. Some programs had to start making an new API call to block SIGHUP killing them. nohup was invented. Some admins probably disabled SIGHUP for a while as it sorted out, and some probably called for these kids and their newfangled signals to get off their lawn. So it goes.

The title is fud. The developer mentions &quot;systemd-run --scope --user tmux&quot; will work just as well. tmux could add this in its default to make it run automatically.<p>This is due to a larger discussion that most users don&#x27;t expect lingering process after logout. <a href="https:&#x2F;&#x2F;github.com&#x2F;systemd&#x2F;systemd&#x2F;issues&#x2F;3382" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;systemd&#x2F;systemd&#x2F;issues&#x2F;3382</a> In these situations, screen&#x2F;tmux must include changes that enforce this behavior. Today the operating system itself does not reap processes ... but systemd is not doing anything wrong. By adding this change, tmux&#x2F;screen users will still get the behavior they expect and the rest of the world get a better behaving operating system.

It will be modular they said. It wont be invasive they said.

It&#x27;s important to remember that it&#x27;s not &quot;those systemd guys&quot; who are breaking everything. It&#x27;s their backer, Redhat. Redhat is leveraging its strong position in the free software ecosystem to bend all Linux distributions to its way of doing things. I think they&#x27;re mostly guided by a desire to keep Canonical penned-in and in a defensive position.

I cannot believe how many people are arguing that they are &#x27;fixing a problem&#x27; or &#x27;adding new functionality&#x27; here. They do neither of those things; and I really hope none of the guys who argued that are writing code in their day job - sad enough those systemd guys that came up with this hack do!<p>The old state of affairs is dependent processes are killed by default on log-out, but there&#x27;s an opt out method.<p>The new state of affairs: dependent processes are killed by default on log-out, but there&#x27;s a <i>new</i> opt out method.<p>The only difference is the old opt-out method is now ignored, in order to reap the misbehaving Gnome processes that use it - until of course those processes adapt to the new API or some other processes do something similar, and we can start the game anew, instead of ever fixing the misbehaving code...

I&#x27;m sorry but this is reasonable. Systemd is fixing <i>real issues</i> with Linux, and if apps rely on old <i>bad</i> behaviour they should be changed to work the new better way.

They claim it is about security but as much as I try to think of a scenario where this would affect a cracker, I can&#x27;t. It will only affect legitimate users, thus systemd is essentially DRM now.<p>Another issue with tmux, is that maybe you want to have your ssh-agent available in it. To do that in a user friendly way, you have to start the ssh-agent first, then start tmux from a shell where you&#x27;ve exported its variables. Good luck with this now...<p>Very dissapointed with RedHat.

That&#x27;s just insulting, it&#x27;s making me want to remove systemd and use something else. As this statement might express: I&#x27;m not a systemd power-user, I just want my stuff to run as I&#x27;d expect it.

It seems that every systemd-related discussion is bound to be filled with all kinds of arguments, but completely devoid of discussion about the actual problem being solved. I can see how the &quot;take no prisioners&quot; attitude from systemd developers encourages this, but it doesn&#x27;t lead anywhere.<p>In this case, the management of user processes is a real problem. It&#x27;s very easy to accumulate lots of forgotten processes on shared machines with long uptimes. Think ad-hoc scripting servers and jumpboxes here. Think nohup&#x27;ed perl scripts that hung waiting for something that&#x27;ll never happen.<p>When you run &quot;screen&quot; or &quot;tmux&quot; you expect them to survive a broken session (i.e. you expect them to behave like an independent session). However, when you run something under &quot;nohup&quot; you mostly expect it to survive the controlling terminal going away (a particular screen window or SSH connection being killed). You may be okay with it being killed if you no longer have a session to the server. A user process running in the background without a controlling terminal isn&#x27;t a service, and from my experience most users don&#x27;t expect it to be. There is a subtle difference between a &quot;session&quot; and a &quot;connection&quot; that&#x27;s not properly implemented without systemd (and can be argued not to be properly implemented _with_ systemd).<p>The thing is how to implement this without &quot;screen&quot; or &quot;tmux&quot; explicitly informing systemd that they want a new session. Touching any API that&#x27;s used beyond terminal multiplexers defeats the whole purpose.

So programs that have no problems whatsoever (like tmux and screen) will have to add linux-specific code to support a systemd feature no one asked for.<p>Nice. (&#x2F;s)

I am sure systemd will just write a replacement for tmux in the long run. After all they know what&#x27;s good for everyone.

This isn&#x27;t really systemd&#x27;s fault. It just happens to have an intrusive solution. Even the solution of using daemon(3) is incorrect (despite having existed for 30+ years).<p>A user_daemon() interface is the Right Way. Processes should not survive past the user session without some fancy footwork, not as a default matter of course. Applications will have to be reworked in some cases, but that&#x27;s because linux has been subject to bad userspace practices all over the place for decades and after the big issues of drivers have been hashed out, time for a little objectivity in handling processes.

Wouldn&#x27;t this mean that on distributions with binary packages, they&#x27;d either have to give tmux a dependency on systemd or they&#x27;d have to make a separate, systemd-less tmux package?

I&#x27;t just a suggestion, if not - tmux users will have issue with systemd services. Not a big deal. I think linux community just loves to overreact everything related to the systemd.

My architectural critique is becoming more pertinent (although they&#x27;ve had the sense to since deprecate the useless snapshot units): <a href="http:&#x2F;&#x2F;blog.darknedgy.net&#x2F;technology&#x2F;2015&#x2F;10&#x2F;11&#x2F;0&#x2F;" rel="nofollow">http:&#x2F;&#x2F;blog.darknedgy.net&#x2F;technology&#x2F;2015&#x2F;10&#x2F;11&#x2F;0&#x2F;</a><p>Either way, dissent is futile. Jump to a niche distro or ditch GNU&#x2F;Linux entirely if systemd bothers you.

Would be bikeshedding, but...<p>I think there is <i>some</i> good intent in systemd&#x27;s change. But they should have approached tmux&#x2F;screen&#x2F;community <i>before</i> making the change and a release which broke things. They should have asked for feedback and such and see if tmux is willing to do what they propose. Simply hammering over things as if you hold powers over other&#x27;s codebases doesn&#x27;t come off as very positive.<p>But oh well...

Playing around with freebsd as the clown operation called systemd continues to unfold.

Looks like stepping away from Unix philosophy of tools with clear boundaries.

what about tmux users on systemd free machines? Do they expect, that everyone have to run systemd now?

Just a note. Slackware is going to do its next release (14.2) some time soon.<p>It&#x27;s nice, no drama, things are where you expect them to be.

So what? Is this that different from, for example, inhibiting a screen saver during video playback?

Worst is that since systemd you have less choices. I&#x27;ve been doing my personal research and while you have a dozen of interesting projects for the desktop there is not that much options for the server specially if your production environment is cloud based.

It&#x27;s fascinating to see the Github emoji responses.

Systemd is destroying Linux. I switched to FreeBSD.

once again we see a comment like: &quot;at this point it might be better stopping people (you know, users) commenting on this in how it affects their day-to-day use of the software&quot;<p>Am I alone in thinking such comments are ostensibly helpful but in fact passive aggressive, because they stifle the user community&#x27;s only relevant channel of complaint?

fly-tipping in userspace

&quot;tmux is not going to use dbus&quot;<p>And that is why I use tmux.<p>As a BSD user I started using tmux as soon as I saw it imported into pkgsrc in 2009. What a pleasant surprise it was, I remember well. I live in textmode and everything about this program&#x27;s design was appealing to me immediately. I am very fussy about software and that is rare. I was so excited I even emailed the developer with a dumb question, which is not something I do very often. He&#x27;s an OpenBSD committer. Surprise.<p>At that time there was virtually no online discussion of tmux that I had seen.<p>In the graphics dominated world we live in, I am amazed at how popular tmux has become.

It seems clear that the systemd devs are not playing well with others, though perhaps I am wrong about that ...<p>Why make such a change instead of just making it optional? What would be the impact in such a case?<p>Did they announce it well in advance and document this?<p>If not, then the question that springs to mind is &quot;I don&#x27;t want these guys in charge of helping me administer my systems.&quot;<p>Imagine updating via apt or yum, and having a bunch of important processes killed with no warning when you log out for the day.

It is a useful feature, and it was already there prior to this version. It could be turned on before, and looking at it, Arch and Debian are going to ignore upstream here (which is unusual for ARch, showing how dumb they think this is) and keep it off by default.<p>All that happened in v230 is that a default of off was flipped to on, nothing more.<p>What people criticize is that a default was change breaking behaviour and biting people who don&#x27;t expect it. The feature is useful for system administrators who want it of course

Am I the only person who likes the idea of being able to logout and log back in again and have all my processes still running and arranged the way I had them? Maybe we just need a &quot;hard logout&quot; option for people who want everything killed.<p>Usually log outs are already instant so I&#x27;m not sure what problem this fixes.

I a unrelated story tmux developers ask systemd developers if systemd can &quot;make me a sandwich&quot; .