4 ms·

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

by jitl 10y ago

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.

kuschku 10y ago
And you can continue doing that with systemd – systemd just requires either tmux or you to mark the process specifically as long running, as, by default, processes will be killed during logout. Making it explicit means you have more control about what will continue to run.
- Sanddancer 10y ago
  That functionality has already existed through the way that tmux already does it, via setsid() and daemon(). Systemd killing everything willy-nilly is a bug.
pstuart 10y ago
The right tool for your scenario is mosh. https://mosh.mit.edu/ https://mosh.mit.edu/
- jdbernard 10y ago
  And the right tool for persistent terminal sessions that span SSH, physical access, VNC, and etc. was tmux until systemd broke it in order to poorly address a problem that primarily affects one DE (GNOME).
tehrei 10y ago
Surely if your SSH session terminates, that doesn't mean your user session terminates, right? You haven't logged off, you've just disconnected, right?
erikb 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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.

by jitl 10y ago

kuschku 10y ago

And you can continue doing that with systemd – systemd just requires either tmux or you to mark the process specifically as long running, as, by default, processes will be killed during logout. Making it explicit means you have more control about what will continue to run.

Sanddancer 10y ago
That functionality has already existed through the way that tmux already does it, via setsid() and daemon(). Systemd killing everything willy-nilly is a bug.

pstuart 10y ago

The right tool for your scenario is mosh. https://mosh.mit.edu/ https://mosh.mit.edu/

jdbernard 10y ago
And the right tool for persistent terminal sessions that span SSH, physical access, VNC, and etc. was tmux until systemd broke it in order to poorly address a problem that primarily affects one DE (GNOME).

tehrei 10y ago

Surely if your SSH session terminates, that doesn't mean your user session terminates, right? You haven't logged off, you've just disconnected, right?

erikb 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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.