[mosh-users] mosh-server processes sticking around?

[C.v.St.]

On 31.01.2014 22:45, Anders Kaseorg wrote:
 >
 > Actually, having tried it (on an Ubuntu 12.04 server), screen -D -R also
 > succeeds for me at killing the mosh-server process, even one in which
 > screen had been attached from inside the shell after login.  ...

The above is the correct behaviour of 'screen -D' (power detach)
resulting in 'hangup' of the session and so end of mosh.

But in some cases this '-D' does not work and the connection
(which might not only be 'mosh' but also 'ssh' or 'rsh' or 'rlogin')
does not end, and then some sessions go idle, like mosh, others run
into endless loops of dead I/O calls, even using 100%CPU sometimes.

One of the classic reasons seem to be 'shell replacements' in
the startup of the session, i.e. something like calling
'bash -l' or 'exec bash -l' inside of 'sh's .profile.

Others semm to happen, if somehow the 'pty' is switched, so
the 'screen' runs on a different pty/## than the mosh created.

May be it is enough to suppress the HANGUP Signal in the
bottom shell (e.g. by 'TRAP .. 0), so the shell below
screen survives. In this case the connection will stay
open.

Just cases I remember from using remote screens for
many years since screen was new and telnet normal :-)

PS.: Having written this so far, I noticed, that it
might (but in case of mosh 'theoretically should not')
depend on the state of the other connections you
want to drop, and is that 'one' or 'many'?
Are those already 'lost' (i.e. client side gone?),
blocked (i.e. by suspended laptop or dead net) or
still running on windows elsewhere.

Mosh handles these cases best of all the connections,
and even works with all the cases in parallel on
a screen, which is attached multiple times from
different places. But rarely even that got hung,
when one of multiple connections got into trouble
by 'sleeping' laptops or dying VPN tunnels. I
always assumed it by chance broke some protocol
of mosh or screen and thusly deadlocked the session.

Stucki