e.g. if under MabaXterm, connected to the remote GNU/Linux server via ssh, I run screen -R dev1, and then nano file.txt, ... if the network drops, the process GNU/nano is killed.
When the connection is unexpectedly dropped, the `nano` process on the remote machine is not terminated, it continues running in the background. The disconnection only affects your terminal SSH session. You can reconnect by starting a new terminal SSH session and attaching to the running `tmux` session that contains your `nano` process. All your work in nano is not lost, because it continue to run and you can finish your work from a new ssh session. The same all stdout/stderr output is not lost, it is stored and will be displayed when you reconnect again.
It shouldn't but it is! That's precisely
the problem

Using MobaXterm (Professional, pay-version) as ssh-terminal, when the connection is unexpectedly dropped(1), the GNU/nano process on the remote machine IS terminated!
- ps -A | grep nano doesn't show GNU/Nano running
- its pid is no more present in /proc/<pid>
- launched as nano file.txt, I see a backup copy file.txt.save
Something somehow terminates it!
It's fixed using a GNU/Linux laptop as ssh terminal.
In this case the GNU/nano process was not terminated. I was still able to see its running PID, but before enabling the -d/-D options in GNU/Screen I was unable to resume the session.
What happens with MobaXterm seems much more drastic, because seriously GNU/Nano crashes, and it also happens with VIM, Joe, ... I tried other text editors. They are all terminated.
And you also have to manually delete the file that screen created for them (Screen says "defunct"), and that remains in ls /tmp/screen/$user like a corpse
server side (GNU/Linux), changes:
/etc/ssh/sshd_config
- TCPKeepAlive no
+ TCPKeepAlive yes
terminal side (GNU/Linux), changes:
recompiled
app-misc/screen with -d/-D options.
(1) edit:
it happens with
a: 802.11 wireless stack, default rate control Minstrel algorithm, connections
b: wireless BATMAN-network mesh connections
c: wired/copper ethernet, 100-baseT connections
never happened with
d: wired/optical ethernet, 100-baseSX connections