On Sat 06 May 2023 at 09:57:30 (+0700), Max Nikulin wrote: > On 05/05/2023 10:30, David Wright wrote: > > On Fri 05 May 2023 at 09:13:04 (+0700), Max Nikulin wrote: > > > On 05/05/2023 02:07, zithro wrote: > > > > 2. using VNC or rdesktop, I then log on to X on the machine, do > > > > some stuff, then hit "log off" from the desktop menu. > > > > Immediately, ALL the previous SSH connections started in step 1 > > > > get closed, hence all the shells and the GUI apps (firefox, etc) ! > ... > > > A wild guess is that it might be force close of systemd user session, > > > however it should not happen. > ... > > Isn't it this issue? > > > > https://news.ycombinator.com/item?id=19023885 > > The discussion is too long.
Yes, I'm not sure I've ever reached the end. If a discussion touches on systemd, then everybody seems to need to get there view out there. > I am aware of "loginctl enable-linger" and > of user logout timeout, but I have no reason to experiment with them > in action yet. Yes, and terminate-user seems effectively to be what happens when you don't use linger. > I have read somewhere that ability to kill all user processes on > logout was a design requirement for systemd. It must have when a > computer is not really "personal": classrooms, public spaces like > libraries. The implementation is to put user's processes into a > cgroup. I hope, recipes to disable such behavior work well. Default > behavior may be disputed, but I would not complain that such feature > exists. If unrelated (ssh) session is killed on (DE) logout due to > disabled lingering than it is a bug. I think it's argued that it was desirable on grounds of security, but is a compile-time option that most distributions have left as the default. I think it exploits the kernel cgroups, which prevent processes from being cast adrift as they were in the past (by double-forking, etc). Such processes can now be grimly reaped when a user logs out and all their resources are returned. Raise that argument for security, and of course you get replies criticising the increased attack surface of systemd, or criticising the change in behaviour from the traditional default, or etc etc. > Systemd configuration might be an issue. As I wrote earlier, I agree > that D-Bus is more probable. It might be PAM configuration for D-Bus > session or systemd user session, it might be some scripts executed on > logout by desktop environment or by login manager. Debugging may take > enough time. It's an area I haven't needed to delve into, and that may be because I don't use DMs and DEs. I can't replicate zithro's Step 2. I run multiple ssh sessions to remote machines, and I run VNC with tightvncserver and xtightvncviewer, but they all seem independent from one another, and never get implicitly killed off. I login to VC1, and startx for an Xserver. I run clients on this and other machines, the latter via ssh -X. That's most of Step 1, except that I don't see a "greeter". Were I to run "ssh -X -n user@host GUI_APP" on a VC, I'd get Can't open display, but prefixed with DISPLAY=:0, the application would open on my Xserver, and the VC would wait for it to be terminated before issuing another prompt. Is the greeter just deferring the ssh command until you login? So I suppose the difference is that when I kill my Xserver, I'm returned to VC1, but not logged off. The question I'll not ask is why do you logoff? Or maybe I will. Cheers, David.
