Rescue SSH session that probably had its buffer... overflow'n

[julianlam]

Messing around on a remote box setting up backups, when I wanted to see what was actually inside a gzip archive.

Normally I'd tar -tvf but this was just a gzipped archive, so I googled and did something dumbpasted the first thing I found:

zcat archive.gz

The archive, by the way, held about a gig of binary data. My terminal filled up with garbage in about 50ms and I couldn't ctrl-c in time.

So, can you actually rescue this borked ssh session, or is the course of action here to just start a new session?

[AlexMedia]

I guess you'll have to wait until zcat has finished its thing, or just start a new session. Depends on how important that specific session is to you :)

[ben_lubar]

@julianlam said in Rescue SSH session that probably had its buffer... overflow'n:

tar -tvf

tar will automatically detect the compression method if you use a file for input.

[ben_lubar]

@julianlam said in Rescue SSH session that probably had its buffer... overflow'n:

So, can you actually rescue this borked ssh session, or is the course of action here to just start a new session?

I mean, there are commands like stty sane. A quick Google shows this as a suggestion: reset; stty sane; tput rs1; clear; echo -e "\033c"

[julianlam]

@ben_lubar You asking me to paste something I found on the internet into my terminal? Host it online and curl | sh the url at least, sheesh.

[pie_flavor]

@julianlam you forgot the sudo.

[PJH]

@julianlam said in Rescue SSH session that probably had its buffer... overflow'n:

So, can you actually rescue this borked ssh session, or is the course of action here to just start a new session?

• Ctrlz to suspend the zcat
• reset to reset the terminal, since displaying binary tends to muck it up.

Then probably

• jobs -ps to get the PID of the suspended job
• kill it.

Ben's list from Google is probably overkill for most situations.

[Tsaukpaetra]

@pjh said in Rescue SSH session that probably had its buffer... overflow'n:

Ben's list from Google is probably overkill for most situations.

So long as most situations didn't splat binary data out to the terminal...

[ben_lubar]

@pjh said in Rescue SSH session that probably had its buffer... overflow'n:

Ctrlz to suspend the zcat

Don't suspend it - kill it using either Ctrl+C (sigint) or Ctrl+\ (sigquit) or pull out another terminal and kill (sigterm) or kill -9 (sigkill) it.

[Tsaukpaetra]

@ben_lubar said in Rescue SSH session that probably had its buffer... overflow'n:

@pjh said in Rescue SSH session that probably had its buffer... overflow'n:

Ctrlz to suspend the zcat

Don't suspend it - kill it using either Ctrl+C (sigint) or Ctrl+\ (sigquit) or pull out another terminal and kill (sigterm) or kill -9 (sigkill) it.

The whole point of this thread is what to do after you've stopped (killed or otherwise) a runaway program. We don't care how you do it, we care what you do after it.

This has been your irregularly scheduled thread-railing-management panda.

[julianlam]

@tsaukpaetra well, ctrl-c didn't actually do anything, since the data probably caused the remote session to freeze :/

[Tsaukpaetra]

@julianlam said in Rescue SSH session that probably had its buffer... overflow'n:

@tsaukpaetra well, ctrl-c didn't actually do anything, since the data probably caused the remote session to freeze :/

Do you have similar issues when doing cat /dev/urandom ?That should do the same thing but without needing a ginormous file...

[PleegWat]

Enter, tilde, period.

[Tsaukpaetra]

@pleegwat said in Rescue SSH session that probably had its buffer... overflow'n:

Enter, tilde, period.