Re: Logging off an X session closes all ssh -X connections started previously from outside X
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.
Reply to: