-   Linux - Networking (
-   -   Lubuntu 12.04 screen lock kills ssh session (

dgermann 01-31-2013 09:16 PM

Lubuntu 12.04 screen lock kills ssh session

Lubuntu 12.04 fresh install. I login from the computer. I then login via ssh from another computer. When the first session screen locks after X minutes, my ssh session is killed or at least locked. When I go back to the physical machine and login, then I can continue my ssh session. How can I shut off this behavior so my ssh session is not interrupted? But I still want the screen saver/lock to work on this machine when I am accessing it remotely.


unSpawn 02-02-2013 07:40 AM

Ssh into the machine then start a 'screen' session? (See 'man screen'.) Even if you get thrown out you can ssh back in again and re-connect to your screen session to find none of your work is lost. (Also see 'autossh' for keeping SSH sessions alive.)

dgermann 02-02-2013 05:11 PM



So is this normal behavior for a host to kill an ssh session when the screensaver kicks in?

I was going to say that I have not had this before, but as I think about it, most of my ssh activity has been to login to headless boxes which are not running X. Or I am in and out quickly such as to run an apt-get upgrade. So maybe this is normal and I have just not seen it.

I will look into autossh and try that, too.

Thanks, unSpawn!

unSpawn 02-02-2013 06:26 PM

If it's the screen saver kicking in I'm sure there's a workaround.

dgermann 02-04-2013 06:54 PM



Well it sure seems to be the screen saver: it coincides with that kicking in.

Any ideas on where to look for a workaround, other than the one you gave me (autossh)? I have googled and asked at several forums, but you are the only person to respond! And I thank you for doing so!

unSpawn 02-04-2013 08:00 PM

I have one Ubuntu LTS but it runs CLI only, no Desktop Environment at all, so no I don't have a clue but I'm willing to think along. Start by finding out what screen saver it runs (probably gnome-screensaver) and look with Gconf-tool (or equivalent) at its scheme, maybe it has some tweaks. If not we'll have to start looking for error messages in /var/log to see what actually kills the session.

dgermann 02-04-2013 08:09 PM


Good thoughts! I will check those out and report back what I find. Thanks!

dgermann 02-05-2013 09:39 PM


Did as you suggested and checked out both dconf-editor and gconf-editor but found nothing. So I did tail -f /var/log/syslog and got some errors about network-manager.

Googling that, I found this: (See the section toward the end about unmanaged wired networks.)

Although I had no file called /etc/NetworkManager/nm-system-settings.conf, I created one and put in the line about managed=true, and rebooted. But alas the same problem.

Here is what tail -f shows:

Feb  5 22:14:41 samba1 NetworkManager[769]: <info> sleep requested (sleeping: no  enabled: yes)
Feb  5 22:14:41 samba1 NetworkManager[769]: <info> sleeping or disabling...
Feb  5 22:14:41 samba1 NetworkManager[769]: <info> (eth0): now unmanaged
Feb  5 22:14:41 samba1 NetworkManager[769]: <info> (eth0): device state change: unavailable -> unmanaged (reason 'sleeping') [20 10 37]
Feb  5 22:14:41 samba1 NetworkManager[769]: <info> (eth0): cleaning up...
Feb  5 22:14:41 samba1 NetworkManager[769]: <info> (eth0): taking down device.
Feb  5 22:14:41 samba1 NetworkManager[769]: <info> (eth1): now unmanaged
Feb  5 22:14:41 samba1 NetworkManager[769]: <info> (eth1): device state change: activated -> unmanaged (reason 'sleeping') [100 10 37]
Feb  5 22:14:41 samba1 NetworkManager[769]: <info> (eth1): deactivating device (reason 'sleeping') [37]

I'm giving up for tonight, and deleting the file I created, but wonder if you see something useful as a clue there?

Thanks for helping me noodle this around!

unSpawn 02-06-2013 08:49 AM

I doubt that but lets try something else:
0.) stop the SSH daemon, then start it manually in debug mode: 'sudo /usr/sbin/sshd -ddd 2>&1 | tee /tmp/sshd.log'
1.) connect but run 'ssh -vvv user@host 2>&1 | tee /tmp/ssh.log' instead.
2.) Now wait until the screen saver kicks in, collect both logs and then check those for clues plus your ~/.xsession-error*, /var/log/auth.log, /var/log/Xorg.0.log, /var/log/messages, /var/log/daemon.log and /var/log/*dm/* log files (if they exist and the time stamps match with your ssh logs).

dgermann 02-07-2013 09:59 PM


Thanks! That is a good suggestion. I will try it when I am not so tired.

Actually I went a step further after I posted the other night and found another file in the same directory which looked like the new name for this nm- file. So I put the entry in there instead, and it still gave me the same errors. So I think you are right about looking in the wrong place.

But I did see that in the gui on the Lubuntu box are power management settings which basically suspend the whole box at X minutes. I am thinking that that is the culprit.

But, for another night's playing....

Thanks, unSpawn!

All times are GMT -5. The time now is 01:13 PM.