Sessions of screen does not keep running in background

[Gustavo A. Díaz]

In a new fresh installed 20.04, when I use screen command and close the terminal (not closing screen sesion), then I can't recover it with screen -x, since does not exist. I can only recover screen sesion if the original terminal running screen is not being closed.

For some reason, this is closing screen session of that user:

Oct 15 13:32:45 pc-caja2 systemd[1]: session-66.scope: Succeeded.
Oct 15 13:32:45 pc-caja2 systemd[1]: Stopped Session 66 of user usuario.

This does not happen in an upgraded system from 18.04 to 20.04.

[Christian Ehrhardt  (paelzer)]

If I "exit" from a screen I'd always expect it is gone.
You'd usually only detach to leave it around like "CTRL+A D" and then you can later reattach.

So you are saying you formerly could

ssh to target and then:
$ screen
 # enters the screen session
$ <do stuff>
$ exit
 # left the screen
$ screen -x
 # this would have re-attached you to the former session?

I'd not have expected this would have ever worked that way.
So I'm assuming you have a slightly different setup, can you explain please how exactly you are entering/leaving the screen session?

[Axel Beckert (xtaran)]

@paelzer: This does not sound like exiting the last shell inside the screen session but closing the xterm/gnome-terminal/lxterminal etc. it is running in. (Back to "New" for that.)

So in the end this sounds a lot like one of these annoying systemd bugs, e.g. similar to https://bugs.debian.org/825394, especially with these systemd messages.

Could though also be the terminal itself, depending on which terminal is actually being used. Never heard of such a case so far, though. So in which terminal did this happen? (Might though validate an "Incomplete" again for this question. Unsure.)

[Christian Ehrhardt  (paelzer)]

Thanks Axel,
I think I didn't closed a terminal windows with anything other but CTRL+D for years (which is an implicit call to exit), but you are absolutely right. It could be "click on the X on the window decoration to close the terminal".
Thanks for making me see that ... :-)

@Gustavo - never the less please speak up what exactly is-done/happens in your case as we are still making assumptions.

[Gustavo A. Díaz (gdiaz)]

Hi, first of all I don' t know why I did' t receive any notification of this bug report.

Second, and to clarify, I being using screen command since 2000 (which Is my beginning as Linux admin). This being said, I know how it works.

All my other Ubuntu upgrades from 18.04 to 20.04, this does not happen (I do not have time yet to test it in a new Ubuntu 20.04, maybe later in a VM).

Simple test: open screen. Just close you terminal (not exit...). When I want to recover screen session with screen -x, is gone, none, nothing...

Btw, I only tested this KDE Neon, which is Ubuntu 20.04 based and I think has nothing to do that is KDE based, since screen has nothing to do with it.

[Guilherme G. Piccoli (gpiccoli)]

That's interesting, I just performed your suggested test, and I couldn't reproduce - it's a fresh Ubuntu 20.04 install, running MATE (not KDE!) and GNU screen 4.8.0-1. After closing the terminal, I've opened another one and "screen -x" worked fine, as expected.

Could you try to use MATE / Gnome to perform your test? So we can isolate it to KDE (or not). Also, which version of screen is installed in your system? Thanks!

[Gustavo A. Díaz (gdiaz)]

Well, is a really close (or same) behaviur like exposed in https://bugs.debian.org/825394 (shared by Axel).

Screen version 4.8.0-1. The system (or either systemd) has modifications at all, so is really weird.

[Christian Ehrhardt  (paelzer)]

Since this started to seem different between Mate&KDE as discussed above I was giving a few more terminals I regularly use a try:
- tilix (VTE based) - warns me that I'll close processes under this session, keeps screen alive detached
- yakuake (kde based) - warns me that I'll close processes under this session, keeps screen alive detached
- konsole - warns me that I'll close processes under this session, keeps screen alive detached
- gnome-terminal - no warning, keeps screen alive detached

So screen never totally died in any of those, just remained detached as one would want/expect.

Since I even tried several KDE based terminals, but not had KDE itself running (I had default gnome based Desktop). I wonder if there might be some general KDE-setting that changes how closing sessions work.

@Gustavo - when you get to retry it on a VM as you mentioned, would you mind trying the same on a KDE-Neon vs a default-Gnome desktop?

[Gustavo A. Díaz (gdiaz)]

Hi,

Sure, I will let you know here the results. Also, I will try to modify login.conf as suggested in the link before doing any test. But anyways, is this was not affected in my other upgrades installations, I don't think that is the problem here, but won't hurt me trying.

[Gustavo A. Díaz (gdiaz)]

Hi,

I did not forgot this, but I reallt didn' t have time to test in a VM.

But, I've installed a new machine with same OS (KDE Neon 20.04) and the same thing happens.

So, like I said before, this does not happen don upgraded machine from 18.04 to 20.04.

I will try to test in VM with Gnome desktop (and Ubuntu 20.04) as soon as I can.

[Utkarsh Gupta (utkarsh)]

Hi Gustavo,

Thanks. Let us know when you've found sometime to do that. No rush, absolutely. Meanwhile I am working this bug as "Incomplete". Please set it back to "New" once you've reported your findings. Thanks!

[Gustavo A. Díaz (gdiaz)]

Ok, today I have some time, I am installing Ubuntu Desktop 20.04 in VirtualBox.

Meanwhile, the only way to keep a session alive (in KDE Neon 20.04) is by using:

systemd-run --scope --user screen

Will keep posted once I've tested in the Ubuntu installation.

[Gustavo A. Díaz (gdiaz)]

Hi,

I can confirm that this does not happen in plain Ubuntu Desktop 20.04. I wonder why in KDE Neon 20.04 does happens since is based in Ubuntu 20.04... I will have to report to them.

Thanks!

[Lucas Kanashiro (lucaskanashiro)]

Thanks for checking Gustavo. Since you mentioned this is not reproducible in Ubuntu 20.04 I'll be marking this bug as Invalid.