1

I decided to dust off my Beaglebone Black Rev.C and figured before I do much of anything, I should get everything up to date. I created an SD card with the new Debian 8.3 image and installed it. No problem.

Using TeraTerm from my Windows 8.1 machine to ssh into the BBB kept ending badly with me apparently getting booted off by the ssh-server. Ugh. So, I fire up a Kali Linux VM and ssh in from there. Pretty much the same. Edit /etc/ssh/ssh_config and added ServerAliveInterval 60. Still getting dropped, but ran apt-get update to completion without getting dropped. Next, I tried apt-get upgrade and it chugged along for quite a long time and then dropped me.

It's been some time and there seems to be no traffic on the LAN that would indicate that apt-get upgrade is still doing anything, but /var/lib/dpkg/ is locked. The process is probably waiting for input from a shell that vaporized.

The question(s):

  1. Is there a way to resolve this politely or should I just reboot?
  2. What's to stop this from repeating ad nauseam? How can I keep my ssh session alive for sure for sure?
Anthon
  • 79,293
Clark Leach
  • 11
  • I think the option ServerAliveInterval is set on the client, e.g. ssh -o ServerAliveInterval=5 -o ServerAliveCountMax=1 myuser@myserver. This is the number of seconds the cliet waits before sending a keep alive packet. Also mentioned here: http://unix.stackexchange.com/questions/3026/what-do-the-options-serveraliveinterval-and-clientaliveinterval-in-sshd-conf – mnille Apr 22 '16 at 05:05
  • I guess I wasn't clear about that; the ServerAliveInterval was set on the client side. I was unaware of ServerAliveCountMax. What does it do? Isn't that a server-side setting? – Clark Leach Apr 22 '16 at 05:22
  • Without ant further changes, the ssh session has now been alive for an hour, at least. Go figure. – Clark Leach Apr 22 '16 at 05:26
  • From the man page (shortened): ServerAliveCountMax => Sets the number of server alive messages (see below) which may be sent without ssh(1) receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session....The default value is 3. If, for example, ServerAliveInterval (see below) is set to 15 and ServerAliveCountMax is left at the default, if the server becomes unresponsive, ssh will disconnect after approximately 45 seconds. – mnille Apr 22 '16 at 05:43

4 Answers4

0

To me it sound like your upgrade restarts a service of some kind which drops your connection. Alternatively you just loose connection, and the mid upgrade state screws with the system, resulting in the need for a reboot.

Typically I would think that a network manager/interface has been upgraded, and "service networking restart" has happened.

The issue here is that when your ssh session is closed, the program/script/whatevs you run in it is closed. Which means that if you run apt-get upgrade, and the session closes, the upgrade is stopped abruptly at same time as the ssh session is closed.

I would suggest to run the upgrade in a screen (I think that would be possible), or hook up an external screen to your Beaglebone.

Magnus Kirø
  • 1
0

SSH actually is pretty stable normally. Maybe you have a faulty setting in your SSHD config (can't tell that without seeing it), or your network has some problems. As a workaround, you could try using Mosh "instead" of SSH, it does a much better job at reconnecting, even if your IP changes or your network connection fails completely for some time.

When closing/dropping an SSH connection, normally the processes running in it are killed by a SIGHUP signal. This means, apt-get most probably isn't running anymore.
But, to check that yourself, you could always run ps aux | grep apt\\-get.
A reboot should do the trick anyways.

Community
  • 1
momar
  • 126
0

How can I keep my ssh session alive for sure for sure?

In your /etc/ssh/sshd_config type in ClientAliveInterval 60 and of course restart sshd service , which will keep you from dropping out of SSH session.

Tolga Ozses
  • 61
0

I recommend you to always use screen when you ssh in to your remote host. 

$ ssh -t username@hostname screen -D -RR

If you would lose connection to your ssh session it's no problem because you can just run the same command again and you'll return back to your screen session with nothing terminated.

The problem with you ssh session not being kept alive long enough, should be fixed if you put the below settings in your ~/.ssh/config or /etc/ssh/ssh_config:

ServerAliveInterval 60
ServerAliveCountMax 10
krt
  • 1,239