0

EDIT: The initial premise of this question was that screen didn't work properly on stock Debian Jessie, and I was looking for workarounds. This turns out to be an artifact of a low sample size -- I have since verified that a fresh Debian Jessie install runs screen correctly, so obviously Something Else is wrong.

The amended question is: I have somehow broken a Debian Jessie system, and the only apparent symptom is that screen sessions terminate on logout, and there's some circumstantial evidence that dbus connectivity might be involved. Can someone suggest what I might have broken?

I realize this changes it to a broad and possibly un-answerable question, but that's where I'm at now.

Original question continues here:

I know there's been some prior discussion of this, but I can't seem to find all the relevant info in one place, and combining disparate sources is not working for me.

I have a stock Debian "jessie" system, and am unable to ssh into it, run background sessions with the "screen" tool, and have them persist after I exit the parent SSH session. I believe I am running into an issue with systemd sessions, and have taken a number of measures that are supposed to fix it, but it's still not working.

I've read the bug report here: Debian bug report 825394. As a consequence of that research, I ensured that user sessions run the "pam_systemd.so" library in /etc/pam.d/common-session, ran "loginctl enable-linger username" for the account in question, and checked that "KillUserProcesses" is set to "no" in /etc/systemd/login.defs.

I have also followed up on the screen "autodetach" setting, from a prior StackExchange post: StackExchange screen question

With these settings, it seems I should be able to do:

systemd-run --scope --user screen

The issue arising from this is that that systemd-run --user wants to connect to the user's dbus session to reach the user's service manager, and ssh connections do not launch dbus, nor, it seems to me, should they -- the whole point of this operation is to do something whose lifetime is longer than that of the enclosing SSH session, which presumably will (and should) tear down the dbus session when it exits.

I have the feeling that I've gone in a circle, and have come back to the problem of wanting a sub-process to persist after log-out.

Debian Jessie currently ships version 215 of systemd, and version 4.2.1 of screen, which does not, as-packaged, include PAM support.

I have a secondary goal of minimizing the level of intervention on the system -- with sufficient guidance, I could probably craft an /etc/pam.d/screen file, but I am hoping for a simpler solution.

Is there a known set of steps for Debian Jessie in particular that will convince systemd to honor my intentions in this case?

4
  • The bug you linked to only ever affected Debian Stretch, Jessie wasn't concerned.
    – Stephen Kitt
    Feb 15, 2017 at 21:41
  • The discussion thread of the bug includes much useful discussion about /etc/systemd/logind.conf and other settings, which seemed relevant. I am open to the possibility that I'm up the wrong tree entirely, of course.
    – Andrew Reid
    Feb 15, 2017 at 21:54
  • Is there any particular reason you want to run screen in a systemd transient scope unit, instead of running screen directly? (The latter works fine on Jessie with the default settings.)
    – Stephen Kitt
    Feb 16, 2017 at 8:01
  • Post edited to reflect new info -- the reason for wanting to run it in the systemd transient scope was because it wasn't working directly, but I have now verified with a fresh install on a VM that it it does indeed work fine on stock Debian Jessie.
    – Andrew Reid
    Feb 16, 2017 at 13:29

2 Answers 2

Reset to default
1

First let's confirm that you are detaching the screen session and not just logging out. The default keybinding to detach is Control-A-D. Details are here.

When you log back in, you use screen -r to resume the session.

1
  • Yes, sorry I was not clear about that. If I detach and don't log out, I can re-attach just fine. If I detach, log out, and log back in, "screen -ls" reports no sessions.
    – Andrew Reid
    Feb 15, 2017 at 21:51
1

So for this particular scenario, it turns out a change to /etc/pam.d/common-session removed the line that connected sessions to systemd. Restoring this line (session optional pam_systemd.so) seems to have fixed the issue.

This is likely specific to a pretty narrow set of circumstances.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .