screen sessions lost after ssh exit

edison-fw / meta-intel-edison

Here is the meta-intel-edison that builds, tries to stay up to date. Master is based on Yocto Poky Gatesgarth LTS 5.10.yy vanilla kernels. It builds a 32bit kernel (Gatesgarth branch 64bit) with ACPI enabled and corresponding rootfs. Telegram group: https://t.me/IntelEdison Web-site:

https://edison-fw.github.io/meta-intel-edison/

MIT License

60 stars 37 forks source link

screen sessions lost after ssh exit #61

Closed sideralis closed 5 years ago

sideralis commented 5 years ago

I have noticed that if I connect to an edison board through ssh, launch a screen session, type for example top and detach, then I can reattach. But if I exit ssh, reconnect through ssh, then there is no more screen sessions available (screen -r does not work and screen -list does not list any sessions). As the session were stored in /tmp, I tried to move them to /run by using SCREENDIR variable. But the problem still remain. I am using sumo version. If someone know how to solve this issue, I will be happy to read.

htot commented 5 years ago

I am on thud. I just tested this by doing screen /dev/ttyS1 115200 and have no problem reconnecting. Same when just doing screen. Maybe the problem is sumo specific?

ochrin commented 5 years ago

Thanks for testing. I will switch on Thud.

sideralis commented 5 years ago

I switched to Thud, but the problem is also here. I think I was not clear in my problem description so here it is:

From your desktop or laptop PC, connect to edison through ssh: ssh 192.168.1.xx
From edison open a screen session: screen, then launch top or htop
From edison, detach from screen: Ctrl A + D
From edison, exit from ssh: exit
From laptop or desktop, reconnect to edison: ssh 192.168.1.xx
From edison, screen -r should reconnect you to your previous and you should see top still displaying data. Unfortunately, this does not work. Never mind, I will investigate and come back if I found the issue.

NB: Ochrin = Sideralis :)

htot commented 5 years ago

@sideralis no you were perfectly clear. I just tried again following exactly your steps (pressing crtl D instead of typing exit) and it just works (htop).

Looks like you found an interesting bug. The only real difference I see is I connect ssh root@edison.local. Is is possible you created a user account, allowing you to connect ssh 192.168.1.xx?

sideralis commented 5 years ago

Yes, I created some user accounts. And I confirm your try: if I 'ssh' to root account (ssh root@192.168.1.xx) then screen session is not lost. If I 'ssh' to user account, screen session is lost. I will try to investigate...

htot commented 5 years ago

I can reproduce your case. Also:

if you have 2 terminals open to edison
create screen and detach in one terminal as non-root
reattach in 2nd terminal and then close first terminal
screen in 2nd terminal terminates

No idea why.

htot commented 5 years ago

@sideralis it's a systemd thingy. Read more here and here (Orphaned processes). Thanks @wdehoog!

What should work (but I didn't try): KillUserProcesses=no in /etc/systemd/logind.conf

compile systemd with --without-kill-user-processes

What certainly does work (I tested):

loginctl user-status
sudo loginctl enable-linger ferry
systemd-run --scope --user screen

So it seems to be intended behavior.

htot commented 5 years ago

If you are looking for a recipe that drops a config fragment to modify logind.conf have a look at the pwr-button-handler after this commit: https://github.com/htot/meta-intel-edison/commit/e07328c33905d74a3ca4f1f271a50c6660d513ad

sideralis commented 5 years ago

Thanks for these details. I modified /etc/systemd/logind.conf on the target and screen is working as expected. I will have a look at your commit. Thanks again.

htot commented 5 years ago

You're welcome. Maybe we should add a topic to the documentation in combination with a patch to enable lingering? In the meanwhile I think we can close this issue?

sideralis commented 5 years ago

Yes, we can close. I am not too familiar with Yocto but I will try to submit a patch for this issue (not right now but in a few weeks).