This is not a constant thing. It does not happen every time but it has happened several times today. Normally I can log in to a remote server and work all day without losing the session. This is not a broken pipe situation. I just get a crosh prompt as though this was a new crosh shell. 

do you have a lot of tabs or otherwise heavy usage in the system ?  there is no guarantee crosh won't be killed under pressure.

plus it really sounds like you should be using Secure Shell if you want to be using ssh.

I may have 25 or more tabs open but this is not abnormal usage for me. I normally have 2 or three crosh shell tabs open and can have them all as active ssh sessions open all day in spite of switching away or even leaving the Chromebook for a period of time. This crashing is unusual behavior in my past two years on Canary but it has briefly occurred on several batches in the past. I may have reported this in the past but it has always been "fixed" a few updates later.

the heuristics as to what tabs/processes to kill frequently change.  i'm not aware of any policy that guarantees crosh won't be reaped.  so at face value, this doesn't sound like a bug.

maybe the heuristics can be improved, but it's not something crosh itself manages.  it is simply "another tab" in the system.

i don't know where that logic lives or who watches over it.

I don't think this is a heuristics issue. There is unused memory. All crosh shells crash. This is NOT a normal situation with crosh. I don't have other tabs crashing. I can collect/capture whatever might be helpful just let me know.

if they were crashing, you should have crashes under chrome://crash.  if there aren't any, i don't think they're crashing, i think Chrome is autokilling them.

I just did an update so I will need to establish some ssh sessions. 
Why would Chrome autokill the crosh tabs? This is highly unusual and as I said, I usually have several ssh sessions going all day without issue. This has changed with a recent update.

as i said, Chrome maintains heuristics as to when to reap tabs, and sometimes it runs experiments to be more aggressive.  but someone familiar with that internal logic would have to comment.

i'm still not sure why you're using crosh+ssh when Secure Shell provides the same thing in a CrOS-sane-form

I don't like the interface with Secure Shell. I have a bunch of scripts and keys that I use and it is far quicker to just use my scripts. 
I have had 4 crash reports this week. 

what are the crashids from chrome://crash ?

chrome://crashes
Uploaded Crash Report ID 2fd680b28432a4dd (Local Crash ID: ChromeOS_ARC)
Crash report uploaded on Friday, July 27, 2018 at 8:50:32 AM

Uploaded Crash Report ID b86ed8e9378a7b5c (Local Crash ID: ChromeOS)
Crash report uploaded on Thursday, July 26, 2018 at 4:20:03 PM

Uploaded Crash Report ID 9d7f9fc81ac3d92b (Local Crash ID: ChromeOS)
Crash report uploaded on Thursday, July 26, 2018 at 11:21:31 AM

Uploaded Crash Report ID 0047b20c2de42ccb (Local Crash ID: ChromeOS)
Crash report uploaded on Wednesday, July 25, 2018 at 11:23:02 AM

Another thing about secure shell is I end up with ssh windows floating around. As tabs, I can put an ssh tab next to a reference doc or copy from the ssh session and paste into a Google Doc.

none of those crashes are related to crosh

Secure Shell can run in tabs just as well as crosh.
copy & paste works exactly the same between the two as they run exactly the same terminal code.

I am willing to say these aren't crashes. I just don't know how to describe it any other way. One minute I have an ssh session, when I switch back to a session, and the screen refreshes to a crosh shell prompt.  Over the last 2 years I have had day long ssh sessions open. Over that 2 year period I have had 2 maybe 3 1 week or so periods where I get this behavior. Not normal behavior.

Just adding more information. I had tried the Secure Shell extension and had not tried the Secure Shell app. The SS extension exhibits the same behavior. When I switch away for a short time (5 - 10 minutes) and come back, the tab or SS extension window is blank and refreshes. The SS extension window does refresh and performs a new login. 
The SS app does, as you indicated, open in a tab. That session does remain active. My connection/session is not lost. 
I do not experience session drops when using CTRL + ALT + -> etc either. Those can remain active all day but not as convenient as a tab and you can't get more than three sessions.

I would like to say, the reports I make are not me complaining. It is just me reporting what I see that is different, unusual, or abnormal. It is why I have used Canary for the past two years. 
At least for the next while I will try the SS app, but will keep an eye on crosh shell tabs. I do believe it is not normal behavior.

In the end, the SS app behaves the same way. 

It has become clear that it isn't the SS app or the crosh shell, It is all my tabs are refreshing as I switch back to them. The results of refreshing a website tab isn't as evident as refreshing an SS app tab. 

i grok that, from your pov, the crosh/ssh tabs are not working ("crashing").  i'm trying to triage to see why so we can route it to the right people.  if it were a crash in crosh, that'd be one group, but if it's the general Chrome browser forcing reloads, that's a diff group.

what would help is to try:
- disable all your extensions then log out/in and see if you still have the tab reload issue
- if you do, reboot the system, then log in, then try to reproduce the tab reloading.  once you do, file feedback via alt+shift+i and mention " crbug.com/868155 " so we can associate your system logs with it.

The tab refresh still occurs with all extensions and Chrome apps disabled. I have also reduced my normal-ish tab count to 23. I have logged out and back in. feedback report sent.

thanks. I'll mark it as a blocker so a tpm can help triage and find an owner.

Many thanks

the feedback report number here is 85574274104

Somehow this bug arrived in my mail, it's as if monorail has become sentient. 

I do have a question though: are the hterm tabs marked as discarded if you open chrome://discards ?

I haven't been as active on my CB today. The 2 hterm tabs I do have open have been constantly active. I will leave them to sit for a while and see. Which column am I looking at? 
Just switched back to a crosh shell session that had an ssh session going and I got the refresh. Back to a crosh shell prompt. Took a screenshot of the discards page with the session in question highlighted.

Deleted: Screenshot 2018-07-31 at 1.34.55 PM.png 134 KB

	Screenshot 2018-07-31 at 1.34.55 PM.png 134 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The second session refreshed as well.

This was a Secure Shell app tab

Deleted: Screenshot 2018-07-31 at 1.39.20 PM.png 181 KB

	Screenshot 2018-07-31 at 1.39.20 PM.png 181 KB View Download

the '1' in the 'discard count' means that this tab was discarded. it probably should never be discarded, so sounds like this should be a bug in that component. Assigning to fdoray.

Thank you!

Another screenshot. 

Deleted: Screenshot 2018-07-31 at 2.26.13 PM.png 264 KB

	Screenshot 2018-07-31 at 2.26.13 PM.png 264 KB View Download

+1 It happens to me nearly *every* time I "pan away" from a window, whether it's SSH in a tab or the standalone "app." Generally it happens whenever I minimize the window (when I bring it back, it's on the SSH App start-up "new connection" window), but it happens anytime the window loses focus. IOW, I can switch to another tab then back, and it's reset. For the standalone app, I have to minimize then maximize to see the reset terminal. This is a P1 blocker for me since I live in my terminal for work.

Release blockers should be P1 or P0

fdoray@'s OOO this week, I'll look into this. 

Extensions that don't want to be discarded should use the chrome.tabs API and set the |autoDiscardable| property to false.

sounds like something needed in the extension then - back to vapier@ to triage.

This happens with the crosh shell as well.

Also, this discard happens on other tabs as well. It isn't as noticeable as an hterm tab but it can be as disruptive on other tabs as well. Filling in a form ???

hterm/crosh should probably set this, and this bug can be about that, in particular calling the API described in #36.

Feel free to pile into issue 853808 if you have views on discarding other tabs.

Do I presume crosh is an extension? Ctrl+Alt+T

The following revision refers to this bug:
  https://chromium.googlesource.com/apps/libapps/+/7811e10a549d91f58f4dfbf045a73c6a958937cb

commit 7811e10a549d91f58f4dfbf045a73c6a958937cb
Author: Mike Frysinger <vapier@chromium.org>
Date: Wed Aug 01 23:51:40 2018

nassh: disable automatic tab discarding

Newer versions of Chrome can be a bit aggressive with automatic tab
discards.  Have nassh/crosh disable that for these sessions since
it is not cheap to restart these sessions.

Bug:  868155 
Change-Id: I7cbf9e09e53996d3faa651f6c81010cbff92797b
Reviewed-on: https://chromium-review.googlesource.com/1159582
Reviewed-by: Vitaliy Shipitsyn <vsh@google.com>
Tested-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/7811e10a549d91f58f4dfbf045a73c6a958937cb/nassh/js/nassh_main.js
[modify] https://crrev.com/7811e10a549d91f58f4dfbf045a73c6a958937cb/nassh/js/crosh.js
[modify] https://crrev.com/7811e10a549d91f58f4dfbf045a73c6a958937cb/nassh/js/nassh.js

this will be in the next R70 (for the bundled crosh), but not R69.  but if the behavior doesn't exist in R69, then it's not a big deal.

i'll prob do a new Secure Shell release this week for (dev), but will be a bit before that makes it into stable.

Thanks! Do you think that it'd be possible to merge this trivial fix in M69? We're planning to enable Proactive Tab Discarding in M69.

I've opened  issue 868155  to discuss the long term options.

we'll prob do a roll of crosh back to M69 this/next week for some a11y changes which will include this

Hi, I'm planning for a M70 Dev push for ChromeOS on Fri. 8/10. I wanted to check to see if this is still considered a blocker for M70. If not can we remove the label. Thanks.

it's been merged into M70, so don't need the blocker labels anymore

R69 merge is being tracked via  issue 863668 

R69 is merged now, so i think that should be good enough

Secure Shell will prob have another update soonish

Finally was able to update to Canary to test this fix. It appears to be fixed for ELM. I was away from my desk for 3  hours. Opened the lid and my active Secure Shell sessions were still active.
I did start using the Secure Shell app in place of ssh from crosh. It works exceedingly well. Thank you Mike!

As of update 10995.0.0 (Official Build) canary-channel elm the tab behavior has reverted to the earlier discard. This bug needs to be revisited. 

I need to examine this more closely. It may be OK after 11003