Hello Axel, first, thank you for the quick response, I am not used to it from the Debian community.
> * Which init system do you use? To me it looks like a "pseudo-hybrid" of SysV and systemd: $ ps axfwu USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.1 0.1 67092 4744 ? Ss 14:27 0:00 init -z root 2 0.0 0.0 0 0 ? S 14:27 0:00 [kthreadd/219364] root 3 0.0 0.0 0 0 ? S 14:27 0:00 \_ [khelper/2193643] root 37 0.0 0.0 43104 1756 ? Ss 14:27 0:00 /lib/systemd/systemd-udevd root 38 0.0 0.0 46036 3316 ? Ss 14:27 0:00 /lib/systemd/systemd-journald root 110 0.0 0.0 37924 2488 ? Ss 14:27 0:00 /lib/systemd/systemd-logind [...] The system is virtualised running on an OpenVZ hypervisor, a virtualisation on OS level, similar to LXC. As we can see, process with PID=1 is not systemd, it's init. I assume it's the hypervisor's init (hypervisor obviously running with SysV), so not virtualised. I don't know about the details of OpenVZ and the setup here. The container where screen is running in it and the hypervisor itself is maintained and operated by the run responsible team. My role here is a software developer, software used by another team, the first level support. >> But I have the same issue with all self-compiled screen binaries, >> the detached screen session was killed after system logout. > > Yes, because that's smells a lot like a systemd issue and not a screen > issue. > > I was thinking of this bug in systemd: https://bugs.debian.org/825394 > > But to my surprise this was actually fixed before Stretch. There one more detail I detected meanwhile. The application running in screen worked for a year impeccably without killed sessions after system logout. What I detected after I reported this bug was, the container was rebooted 30 days ago and since then this issue with screen occurs. > So some more questions: > > * Any chance that there are systemd-sysv and systemd installed on your > system, but the package is not up to date? The most resent release of systemd-sysv and systemd is installed inside the container: $ apt policy systemd-sysv systemd-sysv: Installed: 232-25+deb9u12 Candidate: 232-25+deb9u12 Version table: *** 232-25+deb9u12 500 500 http://debian.schlund.de/debian stretch/main amd64 Packages 100 /var/lib/dpkg/status 232-25+deb9u11 500 500 http://debian.schlund.de/debian-security stretch/updates/main amd64 Packages root@shl-ehb-tool:~# apt policy systemd systemd: Installed: 232-25+deb9u12 Candidate: 232-25+deb9u12 Version table: *** 232-25+deb9u12 500 500 http://debian.schlund.de/debian stretch/main amd64 Packages 100 /var/lib/dpkg/status 232-25+deb9u11 500 500 http://debian.schlund.de/debian-security stretch/updates/main amd64 Packages > * Any chance that you configured systemd with KillUserProcesses=yes in > /etc/systemd/logind.conf? Good point. The unchanged "factory" setting of it is installed, all configuration keys are put in comment below the "[Login]" section which means "KillUserProcesses" defaults to "yes" according the manual page of logind.conf(5). I uncommented the line, so it's "KillUserProcesses=no" and rebooted the container, I did not help - same result. I don't think /etc/systemd/logind.conf was changed before the reboot, I suppose it worked before even with the "factory" setting where "KillUserProcesses" defaults to "yes". >> I installed the tmux package, started a tmux session, detached from >> it and logged out from system. After login, there was no more tmux >> session I can reattach, no more such processes. So Same behaviour. > > Another clear sign that this is no bug in screen. Yes, after this step it was clear to me, it has nothing to do with screen. >> libtinfo5 is a low level terminal library, maintained by Debian, >> derived from libncurses: > > Yeah, but completely unrelated to this issue. > >> I suppose the bug is in libtinfo5 shared library. I placed a binary compatible .so from my workstation in the container and yes, I can confirm, it has nothing to do with libtinfo5 shared library. > But why did you then report the bug against screen then? I asked the same question to myself before I reported the bug. I decided not opening a bug report for libtinfo5. I thought and I hoped to get a little bit more information about the interaction between screen and libtinfo5 in order to get some hints or ideas where to look else in case you can't help here. I expected obtaining more useful information when I go this way first as vice versa, since screen has more dependencies than the shared library and the developer of screen has more detailed know- ledge about interactions with other components. So, from the hints and clues you gave, I wasn't that wrong with my decision. But yes, it hits you, you spent the time going into this for nothing. From developer's point of view I can understand it very well. If it annoyed you - sorry for that. > Anyway, I doubt that libtinfo5 is the culprit. No, it isn't, I agree. The maintainer of the OpenVZ container and hypervisor is informed. Let's see what they say. If you want I can keep you updated if you are interested in it. I think, we can close this bug report. Thank you again. Jürgen
0xA811F9F222306A1E.asc
Description: application/pgp-keys
