mobile-shell / mobile-shell/mosh
Howto/Documentation request — how to deal with long-running sessions
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 14.5k
- Forks
- 865
- PR merge metrics
- No merged PRs in 30d
Description
All,
I mosh into my primary work systems (which are company shell servers in datacenters) with a multitude of devices — three or four of them. (Work laptop, home laptop, always-in-my-bag-laptop, ipad). Sometimes these devices move, sometimes they get rebooted. I also use gnu-screen, which means when I grab my session, all my current sessions are updated in “who” to be [current ip via mosh].
In a world where SSH was a thing, if I reboot my laptop, that session goes away. With mosh, that session hangs around forever, and it’s not obvious to tell which are and aren’t active. When I log in to a system, I get a warning that says “you have an active mosh session”. Yes, of course I do.
What I’d like to do is get the warning if I have more than N active mosh sessions, in my case, 4.
So, from the server side, what is the process one can follow to find any mosh session that hasn’t been “touched” in more than, say, a week, and kill it off? I can’t just look at the age of the sessions, if I’ve been using one for months, actively, I want to keep it. I want to see the “idle time” and that’s not clear from ps, etc.
Related question: Does mosh store any information about the client in its server process? OS Version? Hostname? Something like that? So I can see that a particular server session was started by dans-ipad with blink-terminal? I ask because I’d want to warn not on more than 4 mosh sessons, but sessions from more than 4 devices, which is subtly different.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No file, test, or entry point is named. Start by reviewing how mosh server sessions are represented and what server-side activity or client metadata is available. Done means a how-to can clearly explain identifying inactive sessions, handling a session-count warning, and determining whether device-level tracking is possible.
Written by the indexing model from the issue text.
Assessment
- Domain
- cli, documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 18/100