
Systemd developer asks tmux to add systemd specific code - awalGarg
https://github.com/tmux/tmux/issues/428
======
gpvos
Salient comment: "Or somebody could go find the actual problem @keszybz saw
here - systemd/systemd#3005 - which is: _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 'm much better starting those
again cleanly._ fix that, and stop trying to make systemd break the world
because somebody's gnome session doesn't currently exit cleanly."

~~~
IshKebab
Wait are you saying we should rely on processes behaving nicely? That's not
how you design a robust system. It's why we have pre-emptive multitasking, not
co-operative. And why mobile OSes sandbox applications rather than trusting
them to be good.

~~~
gcb0
I'm not sure I understand, but it seems that systemd is correctly killing
processes when the session ends. and that shell managers like screen and tmux
had hacks to make them survive sessions ends in the past (remember when you
had to use nohup screen?). they seem to simply have asked for tmux to add
their flavor of nohup to the start up check too.

~~~
raverbashing
I would suggest you learn something about Unix before spousing such opinions,
because I don't know where to even begin

nohup is _not a hack_

What systemd is offering has nothing to do with nohup, it's not "a flavour" of
nohup it's a completely different thing

Systemd is not correctly killing processes, this was NEVER DONE LIKE THIS,
they decided this out of a whim because apparently Gnome can't do the right
thing (how surprising)

~~~
LnxPrgr3
Heh--it's like nohup(/daemom), except you make a SOAP call through some
middleware to beg some more middleware for mercy so you can do the thing your
user asked you to do, because everyone's being punished for a few programs'
poor use of the old, more portable API. (I exaggerate, slightly.)

I'm not looking forward to what comes next when Gnome breaks through the new
system.

------
AlexMax
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.

Seems to me like yet another systemd two minute hate. It's getting quite
tiresome to see.

~~~
danudey
I think it's pushback against what a lot of people see as systemd
overreach/arrogance.

"Hey, can you implement and maintain new platform-specific code to work around
this problem we're going to introduce by breaking behaviour of programs using
a 21-year-old API?"

It feels especially egregious because, as commenters pointed out, implementing
the PAM API is a better (and undoubtedly more portable) way to do this that
the developers of systemd didn't seem to consider. Instead, they jumped
straight to "implement a custom fix just for us so our breaking change doesn't
break your app too".

~~~
mwfunk
If it's a reaction against perceived overreach/arrogance, then those people
are just contributing noise to the whole process. People complain about
software development in the corporate world being overinfluenced by
interpersonal politics rather than pure engineering, but stuff like this is
100x worse than almost anything you'll find in the most toxic corporate
environment.

Seriously, every single person who feels compelled to offer their opinion
based on what is an emotional response to Lennart's (or anyone's)
"overreach/arrogance" is contributing little more than noise to the whole
process. It's far too easy for someone who doesn't interact face-to-face with
someone else to fall in a trap of assuming the worst about another person when
there's a technical disagreement; this is a form of cognitive bias that
pollutes development in the corporate world all the time. I'm as guilty of it
as anyone, and I've learned to be wary of the temptation to project bad
qualities on other people who I disagree with but don't interact with
directly.

In the open source world it's so much worse though- not only do almost all
developers interact indirectly (i.e. not face-to-face), but there are
potentially thousands of people who are basically just casual observers who
want to jump in to give their 2 cents. That's great! But it's only great as
long as those 2 cents aren't just people bikeshedding, or actively trying to
make things personal rather than technical. Unfortunately, more often than not
it is bikeshedding, and literally the only thing they have to bikeshed about
is to try to make it personal. :(

~~~
kinkdr
IMHO this is the root cause: Systemd developers trying to use corporate
environment persuading techniques in the open source community.

Instead they should take a step back and rethink their proposed solution every
time they get strong feedback or face some resistance from the open source
community.

------
vessenes
A surprising and troubling comment in the github comments: "Honestly, I don't
see why processes should be able to decide that they should run forever."

I actually let slip an f-bomb reading that. It shows a terrible understanding
of longstanding unix philosophy, (and also straw-mans the argument).

Happily, it doesn't seem that was from a systemd developer as far as I can
tell from their website. Still, it's a reminder that the userbase (and
developer base) that engage with Unix/Linux/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.

~~~
AnonymousPlanet
> Still, it's a reminder that the userbase (and developer base) that engage
> with Unix/Linux/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.

This is a very relevant remark and highlights the root of the entire
discussion, I believe. There seems to be an ideological fault line here. And I
think, it is between those who wish for some ideal, all encompassing design
and those who have been burned by the short sightedness of such ideals. Grand
engineering ideals cemented into closely knit structures are really great on
paper. But some years down the line, you realize you have made too many
commitments, optimizing for something not relevant anymore. And now you have
to circumvent all those greatly engineered structures. It's a bit like looking
at satellite cities, the visions behind them, and what has become of them.

The Unix philosophy is mostly about avoiding those pitfalls. But I guess,
understanding this might only come with experience.

~~~
vessenes
Totally, this is put better than I could have, but is exactly how I feel
watching and experiencing the systemd thing play out. I'm old enough now that
I (I'm such a nerd) don't really want my init system messed around with, but I
do get there may be better ways in general.

In practice though, to me that would mean something that while looking pretty
and being better automated would come with many fewer hidden parts and many
fewer interactions between parts than sysvinit. That is, I'm looking for
simplicity, composability, editability.

The implied technical debt of one system to rule them all is a lot over 20
years, and you will inevitably have to get into line with a dominant system as
a developer downstream from it.

At any rate, happily this behaviour was publicised enough that I won't spend a
day googling it when it happens to me. :)

~~~
AnonymousPlanet
> Totally, this is put better than I could have, but is exactly how I feel
> watching and experiencing the systemd thing play out. I'm old enough now
> that I (I'm such a nerd) don't really want my init system messed around
> with, but I do get there may be better ways in general.

Thanks. I'm kind of in the same boat, age wise. I have the impression (and
this comes from a number of comments online and a podcast with Poettering I
listened to lately) that any criticism from the experienced crowd is seen as a
sort of elitism of people entrenched in their abilities they honed over many
years. This might be the case for many critics, and Poettering may be right to
dismiss them. But I'm afraid that the very valid criticism regarding overall
design goals is lost in all of this. The systemd team steams on, believing
that all naysayers are just stuck in their ways.

------
justinsaccount
Because a project should _never_ have platform specific code.

    
    
      justin@t420:/tmp$ git clone https://github.com/tmux/tmux.git
      justin@t420:/tmp$ cd tmux
      justin@t420:/tmp/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
    

Apparently people have been trying to get tmux fixed for FIVE YEARS NOW

[http://tmux-users.narkive.com/LXp72CHV/pam-support-in-tmux](http://tmux-
users.narkive.com/LXp72CHV/pam-support-in-tmux)

~~~
Scarbutt
Didn't know linux also means systemd.

~~~
justinsaccount
So it's fine to support FIVE different bsd systems (darwin, dragonfly,
freebsd, netbsd, openbsd) but one needs to draw the line at better supporting
the init system used by every major linux distribution.

Okay.

~~~
Sanddancer
The BSD systems have had 20+ years of divergence. There are areas where
they'll borrow from each other when one of the others has a tool that works
better than the status quo, but the kernels are vastly different animals. When
a BSD does make a world-breaking change, like pledge(), it owns it, and will
patch software itself to handle it, not pester upstream to stop what they were
working on to implement their special snowflake code, which is what the
systemd developers want to do.

------
joeyh
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.

~~~
JdeBP
> _Cast your mind back to when SIGHUP first started getting sent to processes
> on logout._

That would be before 1979. nohup was in 7th Edition. I haven't checked 6th.

Ironically, by pointing to the fact that one has to go back through _37 years_
of documentation, education, user experience, and scripts you are making other
people's point for them. Especially by drawing attention to one of the major
flaws in the "nohup was new once" argument, which is that in 1979 (or before)
there wasn't a prior 37 years built up to contradict. (-:

~~~
justinsaccount
I was curious what the oldest reference of it was,

[https://github.com/dspinellis/unix-history-
repo.git](https://github.com/dspinellis/unix-history-repo.git)

has different branches for various unix versions

Seems the earliest reference I could find in there was dated november 1973,
but it is from a full import in 77:

commit c849507974bd2c0e2fd8c17e06f6f65b68075ca9 Author: Bill Joy
<wnj@ucbvax.Berkeley.EDU> Date: Wed Nov 23 12:43:50 1977 -0800

    
    
        Start development on BSD 1
        Create reference copy of all prior development files
        
        
        Synthesized-from: 1bsd
    
    

Some of the earlier copies i can see were even just shell scripts:

    
    
      trap "" 1 15
      if test -t 2>&1  ; then
    	  echo "Sending output to 'nohup.out'"
    	  exec nice -5 $* >>nohup.out 2>&1
      else
      	exec nice -5 $* 2>&1
      fi
    

Research-V3-Snapshot-Development did not have nohup Research-V4-Snapshot-
Development had the nohup man page but not nohup Research-V5-Snapshot-
Development has nohup.c

commit 0281f55d1cf7aa94555d8522d8b37161b97791be Author: Ken Thompson
<ken@research.uucp> Date: Tue Nov 26 18:13:21 1974 -0500

    
    
        Research V5 development
        Work on file usr/source/s2/nohup.c
        
        Co-Authored-By: Dennis Ritchie <dmr@research.uucp>
        Synthesized-from: v5
    
    

Then later v7 reverted back to the shell version

commit 6144d5b3a973b515977eef01a828cdd82c480fe3 Author: Ken Thompson
<ken@research.uucp> Date: Wed Jan 10 15:25:04 1979 -0500

    
    
        Research V7 development
        Work on file bin/nohup
        
        Co-Authored-By: Dennis Ritchie <dmr@research.uucp>
        Synthesized-from: v7

------
sandGorgon
The title is fud. The developer mentions "systemd-run --scope --user tmux"
will work just as well. tmux could add this in its default to make it run
automatically.

This is due to a larger discussion that most users don't expect lingering
process after logout.
[https://github.com/systemd/systemd/issues/3382](https://github.com/systemd/systemd/issues/3382)
In these situations, screen/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/screen users
will still get the behavior they expect and the rest of the world get a better
behaving operating system.

~~~
raverbashing
> but systemd is not doing anything wrong

It's breaking historical behaviour

However making tmux try to use systemd-run is a much better solution than
making it depend on libsystemd

~~~
busterarm
the libsystemd dependency is the goal systemd is trying to achieve though, in
every package.

~~~
okket
[stupid discussion. deleted]

~~~
busterarm
I'm sorry, but the list of packages out there with a libsystemd/libsystemd-*
dependency is massive. I'm not just talking about this specific use case.

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

~~~
busterarm
systemd has turned Linux into a tire fire.

I've spent 20 years with this platform and seriously worry about it being as
useful the next 20.

~~~
zxcvcxz
How has systemd effected you?

~~~
busterarm
It broke a few of my Arch installs. I had to learn a bunch of new tools which
didn't improve my work in any way. The only things that it made easier were
things that were already easy.

More importantly, I think that some of the systemd maintainers have a track
record of not really knowing what they're doing, as exemplified by this tmux
issue. I have serious worry about running their process as PID 1.

Other than that, totally positive effect: It deepened my interest in OS
security and hastened my switch to OpenBSD which was probably happening
anyway.

~~~
jamespo
Arch is an interesting choice of distro if you value stability

~~~
busterarm
For me, Arch very rarely delivered "omg nothing works" moments on upgrade for
me. The only one that I can think of was the systemd upgrade. For every other
breaking change, a fix was either easily apparent or well-documented on the
wiki.

"Stability" in the sense that OpenBSD provides though is something that I
valued more over time of running Arch and my experiences with other things on
the side (mainly QNX).

------
alrs
It's important to remember that it's not "those systemd guys" who are breaking
everything. It'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're mostly guided by a desire to keep
Canonical penned-in and in a defensive position.

~~~
sandGorgon
Redhat funds almost every kernel developer there - including several core
libraries and security.

Canonical does not spend so much on employing core developers and feeds mostly
on upstream.

That in itself is not a problem...but your presumption is wrong. If you track
the systemd inclusion process in Debian, you will find that it was not
subverted but was a free and open fight. Systemd won on its perceived
superiority by people much smarter than me.

~~~
gaius
That's not quite it - it "won" because the Debian project only has the time
and people to support one option, and they got railroaded.

~~~
riyadparvez
I am not sure what is your definition of "won". There is only one option can
be supported, and debian picked systemd over other options. It seems exactly
fits the definition of "won".

~~~
gaius
Perhaps you should re-read your Thucydides, specifically the Melian Dialogue.

------
inflagranti
I cannot believe how many people are arguing that they are 'fixing a problem'
or 'adding new functionality' 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!

The old state of affairs is dependent processes are killed by default on log-
out, but there's an opt out method.

The new state of affairs: dependent processes are killed by default on log-
out, but there's a _new_ opt out method.

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...

------
IshKebab
I'm sorry but this is reasonable. Systemd is fixing _real issues_ with Linux,
and if apps rely on old _bad_ behaviour they should be changed to work the new
better way.

~~~
rincebrain
The problem here, though, is that they're requesting programs which used to be
able to persist via call foo() to call bar() instead if they want to persist
on logout, only on Linux.

As someone in the linked issue remarked, this will end with everyone calling
bar() if they want to persist (the same way they already called foo()), and
we'll still have the same level of persistent process issues, but with a
systemd dependency.

~~~
Spivak
> but with a systemd dependency.

Worse, this isn't "the systemd developers have proposed a new common API for
simplified persistent processes across platforms", but a hard dependency on
this particular revision of the systemd dbus interface, or using the _systemd-
run_ application to generate a user service file.

------
andmarios
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't. It will only affect legitimate
users, thus systemd is essentially DRM now.

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've exported its variables.
Good luck with this now...

Very dissapointed with RedHat.

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

------
CrLf
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 "take no prisioners" attitude from
systemd developers encourages this, but it doesn't lead anywhere.

In this case, the management of user processes is a real problem. It'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'ed
perl scripts that hung waiting for something that'll never happen.

When you run "screen" or "tmux" 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 "nohup" 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't a service, and from my experience most users don't
expect it to be. There is a subtle difference between a "session" and a
"connection" that's not properly implemented without systemd (and can be
argued not to be properly implemented _with_ systemd).

The thing is how to implement this without "screen" or "tmux" explicitly
informing systemd that they want a new session. Touching any API that's used
beyond terminal multiplexers defeats the whole purpose.

------
patrickg_zill
It seems clear that the systemd devs are not playing well with others, though
perhaps I am wrong about that ...

Why make such a change instead of just making it optional? What would be the
impact in such a case?

Did they announce it well in advance and document this?

If not, then the question that springs to mind is "I don't want these guys in
charge of helping me administer my systems."

Imagine updating via apt or yum, and having a bunch of important processes
killed with no warning when you log out for the day.

------
znpy
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.

Nice. (/s)

~~~
GunboatDiplomat
Not just Linux specific, systemd specific.

------
mxc4
I am sure systemd will just write a replacement for tmux in the long run.
After all they know what's good for everyone.

~~~
JdeBP
In theory, the systemd developers could resurrect systemd-consoled as a tmux
replacement. It already had a DEC VT style terminal emulator, knowledge of
these systemd abstractions, and Desktop Bus capability.

But as pointed out already on this page, that would be to miss the wood for
the trees. There are _many_ programs that are hit by the fact that they call
daemon() with the idea of escaping being killed at the end of the login
session and yet are still (now, as of systemd version 230) killed by systemd
at (final) logout. The systemd developers themselves mentioned screen and
tmux. But others have already mentioned mosh-server and deluged (ironically in
the bug report that supposedly drove this systemd change). It will almost
certainly affect things like emacs --daemon as well. The list grows on and on.

* [http://askubuntu.com/questions/338135/](http://askubuntu.com/questions/338135/)

* [http://blog.refu.co/?p=1296#comment-61675](http://blog.refu.co/?p=1296#comment-61675)

Should the systemd developers fork emacs so that they have a logind-aware
version of emacs --daemon?

------
jack9
This isn't really systemd'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).

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'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.

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

~~~
Shish2k
It might depend on libdbus, but it wouldn't require systemd to be installed
and running

~~~
thescribe
What about systems that don't have or need libdubs. Tmux does not depend on
dbus.

------
Gonzih
I'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.

------
vezzy-fnord
My architectural critique is becoming more pertinent (although they've had the
sense to since deprecate the useless snapshot units):
[http://blog.darknedgy.net/technology/2015/10/11/0/](http://blog.darknedgy.net/technology/2015/10/11/0/)

Either way, dissent is futile. Jump to a niche distro or ditch GNU/Linux
entirely if systemd bothers you.

------
awalGarg
Would be bikeshedding, but...

I think there is _some_ good intent in systemd's change. But they should have
approached tmux/screen/community _before_ 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's codebases doesn't come off as very positive.

But oh well...

~~~
NeutronBoy
Some of the other comments in this thread indicate that tmux not confirming to
the specification is a known issue that people have been trying to get fixed
for a few years. I'm not knowledgeable enough to know how correct this is, but
it appears that it's not an entirely one-sided argument.

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

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

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

------
jimjimjim
Just a note. Slackware is going to do its next release (14.2) some time soon.

It's nice, no drama, things are where you expect them to be.

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

------
olakease
Worst is that since systemd you have less choices. I'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.

------
hosh
It's fascinating to see the Github emoji responses.

------
sunseb
Systemd is destroying Linux. I switched to FreeBSD.

------
gjvc
once again we see a comment like: "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"

Am I alone in thinking such comments are ostensibly helpful but in fact
passive aggressive, because they stifle the user community's only relevant
channel of complaint?

------
nthcolumn
fly-tipping in userspace

------
feelin_googley
"tmux is not going to use dbus"

And that is why I use tmux.

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'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's an OpenBSD committer. Surprise.

At that time there was virtually no online discussion of tmux that I had seen.

In the graphics dominated world we live in, I am amazed at how popular tmux
has become.

~~~
digi_owl
Its because even though most personal computers have a GUI, most of the
development and configuration of the internet happens via text.

------
kolapuriya
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.

All that happened in v230 is that a default of off was flipped to on, nothing
more.

What people criticize is that a default was change breaking behaviour and
biting people who don't expect it. The feature is useful for system
administrators who want it of course

------
zxcvcxz
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 "hard logout" option for people who want everything
killed.

Usually log outs are already instant so I'm not sure what problem this fixes.

~~~
chrisper
If you want your processes to be running the way it is, then just lock your
screen or switch user instead of log out. A log out, in my opinion is like a
shutdown of the user session. So all user processes should stop running.

~~~
jitl
So I should loose my state when I disconnect from my SSH session because my
train went through a tunnel? This attitude might make sense on a desktop GUI
machine, but in the real world far more developers use Linux remotely over
SSH, which is where tmux really shines. I use it to leave my "IDE" (vim and
friends) running on my server, so I can resume work remotely from any
computer.

~~~
erikb
That post is confusing problem with solution. When you lose your ssh
connection you are not logging out on purpose. Even ssh can help you there,
though. You can configure ssh clients (and also servers I believe) to survive
a session to be gone for minutes, even hours if you desire.

So your problem is that you haven't spent enough time learning to configure
your ssh according to your needs. The cool thing is that ssh configs can be
done for a specific session (if it happens just once in a while or you
experiment about the right configuration), it can be done per target (in case
you want to react differently on your personal blog and your company
development host), and globally (to apply always). Have fun reading. You may
find that ssh can solve a lot of problems and in some people's mind even
solves problems like other tools but more elegant (I personally prefer it over
http-proxys and VPNs as well).

~~~
jdbernard
No. I often purposefully log out of an SSH session and expect to come back
later and have my tmux session still the same. Sometimes I log out of my
desktop at home that I'm physically at, get to someplace else, log in via SSH,
and reconnect to the same tmux session I had running when I was at home. This
is one of the primary features of tmux. It's not about misconfigured SSH
sessions.

~~~
erikb
Yes you are right. In that case you have tmux to keep your session. If it
doesn't do it, it's pretty much tmux's fault. I understood the previous
message as if losing the connection on a train ride would be the main issue.

~~~
jdbernard
How is it tmux's fault when it is systemd that is killing processes? Tmux uses
the standard mechanism to inform the system that it should live on, systemd no
longer respects that mechanism.

------
shiftoutbox
I a unrelated story tmux developers ask systemd developers if systemd can
"make me a sandwich" .

