Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Vincent Lefevre]

On 2023-05-10 09:28:51 -0400, Greg Wooledge wrote:
> On Wed, May 10, 2023 at 03:19:31PM +0200, Vincent Lefevre wrote:
> > On 2023-05-10 15:07:17 +0200, Vincent Lefevre wrote:
> > > Note: if you play with .ssh/rc, be careful as there is a risk
> > > that you may not log in any more with ssh in case of mistake
> > > (I'm wondering whether there is an undocumented way to skip it).
> > 
> > For this point, there are solutions there:
> > 
> >   https://unix.stackexchange.com/q/458445/74516
> > 
> > But this needs to update the setup on the server first.
> 
> A sensible precaution when mucking around with things that could affect
> your account's login is to ensure there's a second account you can
> log into in case you break the first one.  Also, ensure that the second
> account can run either "sudo" or "su" or some other privilege elevation
> command, so that you can fix the first account from the second.
> 
> (Of course, if the second account is root, then no elevation is needed.)

For hosts where one is the admin, alternative ways are needed
(e.g. physical access or some form of console login), as even
ssh may break globally. A second account is not much useful in
such a case (unless user-level breakage is common).

For hosts where one isn't the admin, it is often not really
possible to have a second account. And the alternate key solution
described at the above URL is possible in such a case.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Greg Wooledge]

On Wed, May 10, 2023 at 03:19:31PM +0200, Vincent Lefevre wrote:
> On 2023-05-10 15:07:17 +0200, Vincent Lefevre wrote:
> > Note: if you play with .ssh/rc, be careful as there is a risk
> > that you may not log in any more with ssh in case of mistake
> > (I'm wondering whether there is an undocumented way to skip it).
> 
> For this point, there are solutions there:
> 
>   https://unix.stackexchange.com/q/458445/74516
> 
> But this needs to update the setup on the server first.

A sensible precaution when mucking around with things that could affect
your account's login is to ensure there's a second account you can
log into in case you break the first one.  Also, ensure that the second
account can run either "sudo" or "su" or some other privilege elevation
command, so that you can fix the first account from the second.

(Of course, if the second account is root, then no elevation is needed.)

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Vincent Lefevre]

On 2023-05-10 15:07:17 +0200, Vincent Lefevre wrote:
> Note: if you play with .ssh/rc, be careful as there is a risk
> that you may not log in any more with ssh in case of mistake
> (I'm wondering whether there is an undocumented way to skip it).

For this point, there are solutions there:

  https://unix.stackexchange.com/q/458445/74516

But this needs to update the setup on the server first.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Vincent Lefevre]

On 2023-05-10 14:36:25 +0200, Vincent Lefevre wrote:
[...]
> zira:~> ssh cventin xterm
> Connected to cventin (from 140.77.51.8)
> OS: Debian GNU/Linux 12 (bookworm) [x86_64]
> DISPLAY: localhost:11.0
> 
> and xterm is started as expected. FYI, some data, like DISPLAY, are
> output by my .ssh/rc script (I've attached it and the associated
> .ssh/xauth.wrapper Perl script too, in case this can be useful).

Note: if you play with .ssh/rc, be careful as there is a risk
that you may not log in any more with ssh in case of mistake
(I'm wondering whether there is an undocumented way to skip it).

For details, see the sshd(8) man page.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Vincent Lefevre]

On 2023-05-09 20:07:26 +0200, zithro wrote:
> On 09 May 2023 18:06, Vincent Lefevre wrote:
> > On 2023-05-05 15:04:27 +0200, zithro wrote:
> > > 
> > > journalctl after GUI LOGOFF
> > > 
> > [...]
> > > May 05 14:09:14 debzit sshd[14246]: Received disconnect from IP.IP.IP.IP
> > > port 38524:11: disconnected by user
> >   
> > 
> > "disconnected by user": Doesn't this mean that it is the client that
> > did the disconnection (for whatever reason)?
> 
> I dunno, but it happens when the server-side logoff is requested from X ...
> Can't see the relation : how can a server X logoff send a request to the ssh
> command on the client ?!?!

I agree that this is strange.

> However I just tried, I killed an ssh session from the server, didn't get
> the "disconnect" message in logs.
> Although I don't know if killing (via SIGTERM) is equivalent to what
> whatever the system uses to close the ssh sessions when my problem is
> happening.

You can also try with SIGHUP (but I would be surprised if the result
were different).

> > This is the message I observe when I disconnect the ssh session from
> > the client (with "~.") instead of terminating the program (e.g. shell)
> > on the server side.
> 
> Same here for normal exits, or I think so ?
> I use Ctrl-D to close ssh sessions, "~." does not work, I get "bash: command
> not found".

As Greg said, you need to type [Enter] first (otherwise the escape
character would be triggered too often).

FYI, in the ssh(1) man page:

  -e escape_char
  Sets the escape character for sessions with a pty (default: ‘~’).
  The escape character is only recognized at the beginning of a
  line.  The escape character followed by a dot (‘.’) closes the
  connection; followed by control-Z suspends the connection; and
  followed by itself sends the escape character once.  Setting the
  character to “none” disables any escapes and makes the session
  fully transparent.

Note that Ctrl-D terminates the remote shell, which has the effect
to terminate the ssh session *from the server* (the remote side).
On the contrary, "~." at the beginning of a line terminates the
ssh session on the client side (the escape character is interpreted
by the ssh client, and the sshd server does not see it).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Vincent Lefevre]

On 2023-05-09 14:17:14 -0400, Dan Ritter wrote:
> zithro wrote: 
> > On 09 May 2023 17:47, Vincent Lefevre wrote:
> > > BTW, you should also try GNU Screen to see if you have the same issue
> > > with it (this could help debugging).
> > 
> > Do you mean trying "ssh u@h screen" ?
> > Never tried screen with GUI apps, does that work ?
> 
> Not in a useful way. For the equivalent of screen for X11, you
> can try nxagent or workarounds like xvnc.

Note that I suggested to try screen just for *testing* in order to
try to find the cause of the issue (e.g. whether the killed ssh's
are specific to ssh or other processes that shouldn't be killed,
like screen, are also affected), not to use it with GUI apps.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Vincent Lefevre]

On 2023-05-09 19:44:48 +0200, zithro wrote:
> On 09 May 2023 17:47, Vincent Lefevre wrote:
> > Hi,
> > 
> > On 2023-05-04 21:07:17 +0200, zithro wrote:
> > > Here is what happens chronologically :
> > > 
> > > 1. I start various SSH connections to a host, some normal, some with X
> > > forwarding, like that: "ssh user@host" and "ssh -X -n user@host GUI_APP"
> > > (like firejail firefox, firejail thunderbird, etc). There's no user
> > > connected under X yet, only the greeter is displayed.
> > > 
> > > 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) !
> > 
> > I have a similar setup (I also use lightdm and systemd) and do the
> > same kind of thing, but I haven't noticed any such issue.
> 
> Damn, now I wanna know the differences between our setups ^^
> Do you also have several DE installed (but not running concurrently) ?

No DE, just fvwm2.

> > BTW, you should also try GNU Screen to see if you have the same issue
> > with it (this could help debugging).
> 
> Do you mean trying "ssh u@h screen" ?

You need a terminal. Just do "ssh u@h" to start a remote shell.
Run "screen" from the remote shell. Detach the screen session.
You should be able to see the screen process (it should appear
as "SCREEN") with "ps -fwC screen". Then do an X login/logout.
I suppose that the ssh will terminate (as you described). Do a
"ssh u@h" again. And see if the screen process is still there
or if it has been killed at the logout.

If it has been killed, you may try again with:
1. ssh u@h
2. Start screen.
3. Detach the session.
4. Check with "ps -fwC screen" that screen is still running.
5. Log out from the ssh session.
6. ssh u@h
7. Check with "ps -fwC screen" whether screen is still running.

i.e. whether it has been killed at the ssh logout at step 5 (if
it has been killed, then I suppose that the issue is related to
any logout, not just X logout).

> As said in other posts, dunno how user lingering is configured on my setups.

loginctl user-status 

In my case, for the machine at my lab:

vlefevre (1000)
[...]
  Linger: no
[...]

On my VM, where I use lingering, I get:

vinc17 (1000)
[...]
  Linger: yes
[...]

> > I never use the -X ssh option, but I use X11 forwarding by default
> > (ForwardX11 yes), so I suppose that this is equivalent to -X.
> > 
> 
> No, AFAIK "ForwardX11 yes" is just to *allow* X11 forwarding, not to enable
> it on all ssh connections.
> Ie. running "ssh u@h GUI_APP" without "-X" does not provide the DISPLAY var,
> and so fails running GUI_APP with "Unable to init server: Could not connect:
> Connection refused".

I don't have any such issue. For instance,

zira:~> ssh cventin xterm
Connected to cventin (from 140.77.51.8)
OS: Debian GNU/Linux 12 (bookworm) [x86_64]
DISPLAY: localhost:11.0

and xterm is started as expected. FYI, some data, like DISPLAY, are
output by my .ssh/rc script (I've attached it and the associated
.ssh/xauth.wrapper Perl script too, in case this can be useful).

> Do you use "UsePAM yes" in sshd_config (server-side option only) ?

Yes (this is the default, and I haven't changed it).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
# Vincent Lefevre's .ssh/rc file -*- sh -*-

# To avoid unexpected interaction with programs that send their data to
# stdout (e.g. svn when using the svn+ssh scheme), output every message
# to stderr. But be careful! When the -t option (pseudo-tty allocation),
# is used, stderr is redirected to stdout.

# The terminal name (pathname) is given by $SSH_TTY, as documented in
# the ssh(1) man page, and this doesn't depend on the shell that runs
# this script (the login shell of the user).

# Uncomment the following line to output $0 in order to know what pathname
# is used for this .ssh/rc script and can be tested by the .zshenv startup
# file via "$ZSH_EXECUTION_STRING".
#echo "Script: $0" >&2

case "$OSTYPE" in
  solaris*)  ip="$(echo $SSH_CONNECTION | sed 's/ .*//')";;
  *) ip="${SSH_CONNECTION%% *}";;
esac

: ${HOST:=$(hostname)}
echo "Connected to $HOST (from $ip)${SSH_TTY:+ on $SSH_TTY}" >&2

if [ -r /etc/os-release ]; then
  . /etc/os-release
  echo "OS: $PRETTY_NAME [$(uname -m)]" >&2
fi

# In particular, the following will set the IUTF8 flag when needed.
# But we assume that the locale settings have been correctly passed.
# Code that fixes the locale settings (e.g. due to Debian bug 313317
# or https://bugzilla.mindrot.org/show_bug.cgi?id=1346 upstream bug)
# will need to rerun the following script.
if [ -n "$SSH_TTY" ] && [ -f $HOME/.stty ]; then
  alias stty="stty -F $SSH_TTY"
  . $HOME/.stty
fi

if [ -n "$DISPLAY" ]; then
  echo "DISPLAY: $DISPLAY" >&

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Dan Ritter]

zithro wrote: 
> On 09 May 2023 17:47, Vincent Lefevre wrote:
> > BTW, you should also try GNU Screen to see if you have the same issue
> > with it (this could help debugging).
> 
> Do you mean trying "ssh u@h screen" ?
> Never tried screen with GUI apps, does that work ?

Not in a useful way. For the equivalent of screen for X11, you
can try nxagent or workarounds like xvnc.

-dsr-

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Greg Wooledge]

On Tue, May 09, 2023 at 08:07:26PM +0200, zithro wrote:
> I use Ctrl-D to close ssh sessions, "~." does not work, I get "bash: command
> not found".

To use the tilde commands in the ssh client, they have to be at the
"beginning of a line", which means you have to press Enter first.  Or
at least have the ssh client in a position where it believes you've
pressed Enter recently enough.

For my own sanity, I just think of them as 3-character sequences,
  Enter ~ .  and so on.

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[zithro]

On 09 May 2023 18:06, Vincent Lefevre wrote:

On 2023-05-05 15:04:27 +0200, zithro wrote:


journalctl after GUI LOGOFF


[...]

May 05 14:09:14 debzit sshd[14246]: Received disconnect from IP.IP.IP.IP
port 38524:11: disconnected by user

  

"disconnected by user": Doesn't this mean that it is the client that
did the disconnection (for whatever reason)?


I dunno, but it happens when the server-side logoff is requested from X ...
Can't see the relation : how can a server X logoff send a request to the 
ssh command on the client ?!?!


However I just tried, I killed an ssh session from the server, didn't 
get the "disconnect" message in logs.
Although I don't know if killing (via SIGTERM) is equivalent to what 
whatever the system uses to close the ssh sessions when my problem is 
happening.



This is the message I observe when I disconnect the ssh session from
the client (with "~.") instead of terminating the program (e.g. shell)
on the server side.


Same here for normal exits, or I think so ?
I use Ctrl-D to close ssh sessions, "~." does not work, I get "bash: 
command not found".



[...]

May 05 14:09:14 debzit sshd[14113]: Received disconnect from IP.IP.IP.IP
port 38512:11: disconnected by user

[...]

Ditto.


Yep, as it's just another ssh session started the exact same way than 
the others ;)




Starting the ssh session with "ssh -vvv" might help to find the reason.



Yes, need to test that too ...

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[zithro]

On 09 May 2023 17:47, Vincent Lefevre wrote:

Hi,

On 2023-05-04 21:07:17 +0200, zithro wrote:

Here is what happens chronologically :

1. I start various SSH connections to a host, some normal, some with X
forwarding, like that: "ssh user@host" and "ssh -X -n user@host GUI_APP"
(like firejail firefox, firejail thunderbird, etc). There's no user
connected under X yet, only the greeter is displayed.

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) !


I have a similar setup (I also use lightdm and systemd) and do the
same kind of thing, but I haven't noticed any such issue.


Damn, now I wanna know the differences between our setups ^^
Do you also have several DE installed (but not running concurrently) ?


BTW, you should also try GNU Screen to see if you have the same issue
with it (this could help debugging).


Do you mean trying "ssh u@h screen" ?
Never tried screen with GUI apps, does that work ?


More precisely, I have 2 machines: one at home and one at my lab.
At home, I have an almost persistent X session (I log out only
when I need), and from it I ssh to my machine at my lab and keep
this ssh session open also almost persistently.

At my lab, I log in when I arrive and always log out when I leave,
but this never affects the ssh session I have at home.

Note also that I normally also have a GNU Screen running on both
machines (but not always). In any case, the X login/logout via
lightdm at my lab never affects ssh and GNU Screen.


Dammit (although happy for you ^^).


User lingering is disabled on both machines. And no changes to
logind.conf at my lab (KillUserProcesses is "no" by default).


As said in other posts, dunno how user lingering is configured on my setups.
Tried to grep "linger" in /etc (on server), only found references to 
SElinux.
logind.conf also has "#KillUserProcesses=no". Can it be declared 
elsewhere, ie. outside of /etc ?




I never use the -X ssh option, but I use X11 forwarding by default
(ForwardX11 yes), so I suppose that this is equivalent to -X.



No, AFAIK "ForwardX11 yes" is just to *allow* X11 forwarding, not to 
enable it on all ssh connections.
Ie. running "ssh u@h GUI_APP" without "-X" does not provide the DISPLAY 
var, and so fails running GUI_APP with "Unable to init server: Could not 
connect: Connection refused".

Do you use "UsePAM yes" in sshd_config (server-side option only) ?

Thanks for your input, it confirms it's a problem in my config, not in 
the software.

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Vincent Lefevre]

On 2023-05-05 15:04:27 +0200, zithro wrote:
> 
> journalctl after GUI LOGOFF
> 
[...]
> May 05 14:09:14 debzit sshd[14246]: Received disconnect from IP.IP.IP.IP
> port 38524:11: disconnected by user
 

"disconnected by user": Doesn't this mean that it is the client that
did the disconnection (for whatever reason)?

This is the message I observe when I disconnect the ssh session from
the client (with "~.") instead of terminating the program (e.g. shell)
on the server side.

[...]
> May 05 14:09:14 debzit sshd[14113]: Received disconnect from IP.IP.IP.IP
> port 38512:11: disconnected by user
[...]

Ditto.

Starting the ssh session with "ssh -vvv" might help to find the reason.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Vincent Lefevre]

Hi,

On 2023-05-04 21:07:17 +0200, zithro wrote:
> Here is what happens chronologically :
> 
> 1. I start various SSH connections to a host, some normal, some with X
> forwarding, like that: "ssh user@host" and "ssh -X -n user@host GUI_APP"
> (like firejail firefox, firejail thunderbird, etc). There's no user
> connected under X yet, only the greeter is displayed.
> 
> 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) !

I have a similar setup (I also use lightdm and systemd) and do the
same kind of thing, but I haven't noticed any such issue.

BTW, you should also try GNU Screen to see if you have the same issue
with it (this could help debugging).

More precisely, I have 2 machines: one at home and one at my lab.
At home, I have an almost persistent X session (I log out only
when I need), and from it I ssh to my machine at my lab and keep
this ssh session open also almost persistently.

At my lab, I log in when I arrive and always log out when I leave,
but this never affects the ssh session I have at home.

Note also that I normally also have a GNU Screen running on both
machines (but not always). In any case, the X login/logout via
lightdm at my lab never affects ssh and GNU Screen.

User lingering is disabled on both machines. And no changes to
logind.conf at my lab (KillUserProcesses is "no" by default).

I never use the -X ssh option, but I use X11 forwarding by default
(ForwardX11 yes), so I suppose that this is equivalent to -X.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[zithro]

On 06 May 2023 07:07, to...@tuxteam.de wrote:

On Sat, May 06, 2023 at 10:24:52AM +0700, Max Nikulin wrote:


Thanks both for the pointers, will report back with results

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[zithro]

On 05 May 2023 19:14, Max Nikulin wrote:

Does it happen for newly created user with no customization?


Never tried !


I recommended to do it just for a case that you added something to init 
files for the "zithro" user.


AFAIK I didn't customize a lot, as I'm rarely logging to X.
But it won't hurt trying ! Will do and report back

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[zithro]

On 06 May 2023 06:45, David Wright wrote:


*I login to VC1 and startx for an Xserver*


I think that's why you don't have my problem, your user is always logged 
in, even when you close X.



Is the greeter just deferring the ssh command until you login?
Nope, they work without X "direct" login. I even rarely login to X 
before ssh-ing.



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.


Ahah ^^ (and yes for your logoff, as said above).
Yeah, I could as well keep the X login open till I close all ssh 
sessions, but it's using ressources for nothing.
Except NOT logging in X (which I rarely do), the quickest fix would be 
to remove systemd altogether, it's only there because it's Debian's 
defaults.
I just dunno if it's as easy on my setup than on non-X+DE/DM, where it's 
kinda easy.

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Max Nikulin]

On 05/05/2023 12:33, David wrote:

That sounds like what is documented here, with the solution at the end:

$ apt show dbus-user-session


I have tried quite similar steps, it seems the cause is not 
dbus-user-session per se.


I have a laptop with Debian 11 bullseye and "minimalistic" KDE 
(originally installed without DE, some packages added later). 
dbus-user-session is an automatically installed package there.


- ssh -X -n that-laptop firefox
- login from sddm (built-in keyboard and screen)
- logout from KDE session

firefox on remote display is still running, so I can not confirm the issue

ssh remote session:
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1001/bus
local KDE session
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1001/bus,guid=abcdabcdabcdabcdabcdabcdabcdabcd

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[tomas]

On Sat, May 06, 2023 at 10:24:52AM +0700, Max Nikulin wrote:
> On 05/05/2023 20:04, zithro wrote:
> > journalctl after GUI LOGOFF
> 
> I do not see obvious problems. What might be inspected more closely:
> 
> > May 05 14:09:14 debzit systemd[711]: Stopping D-Bus User Message Bus...
>^^^
> If it is the bus shared with ssh connection than it may be an issue,
> however it is for systemd unit, real process may be running independently.

This would be easy to find out. @zithro: how many instances of dbus
are running once you have started all your processes *and* logged
in to the DE session?

If it's only one user dbus, then logging out is taking that one away.

Perhaps this would be an interesting data point:

 1 ps wwaux | grep dbus; keep the result
 2 start all your programs; don't log in into your DE yet
 3 repeat 1
 4 log into your DE
 5 repeat 1
 6 log out; your programs get killed
 7 repeat 1

Now compare the results of 1, 3, 5 and 7. Then,we would know whether
your DE is re-using the user session bus (possibly) started at 2
and taking it out at 6.

This is my hunch.

Then, at least, you'd know whom to yell at :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[David Wright]

On Fri 05 May 2023 at 13:59:37 (+0200), zithro wrote:
> On 05 May 2023 07:33, David wrote:
> > On Thu, 4 May 2023 at 19:07, zithro  wrote:
> > 
> > > this is a rather strange problem, I hope the title is explicit enough.
> > 
> > Subject: Logging off an X session closes all ssh -X connections
> > started previously from outside X
> 
> Yeah, I meant title==subject, I was hoping it was clear enough for everyone.
> Why did you copy it ? ^^

https://lists.debian.org/debian-user/2023/04/msg01060.html

Cheers,
David.

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[David Wright]

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.

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Max Nikulin]

On 05/05/2023 20:04, zithro wrote:

journalctl after GUI LOGOFF


I do not see obvious problems. What might be inspected more closely:


May 05 14:09:14 debzit systemd[711]: Stopping D-Bus User Message Bus...

   ^^^
If it is the bus shared with ssh connection than it may be an issue,
however it is for systemd unit, real process may be running independently.

Perhaps there is a specific command, but at leas you may compare
env | grep -i bus

from ssh and from GUI sessions. Output may be like
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus


May 05 14:09:14 debzit gvfsd[14302]: A connection to the bus can't be made
May 05 14:09:14 debzit systemd[711]: xdg-permission-store.service: Main 
process exited, code=exited, status=1/FAILURE

...

May 05 14:09:14 debzit systemd[711]: Stopped D-Bus User Message Bus.
May 05 14:09:14 debzit systemd[711]: Started D-Bus User Message Bus.


Why it started again from the same systemd user session if it is logout? 
I would compare with logout messages when there are no ssh connections.


May 05 14:09:14 debzit sshd[14246]: Received disconnect from IP.IP.IP.IP 
port 38524:11: disconnected by user
May 05 14:09:14 debzit sshd[14246]: Disconnected from user zithro 
IP.IP.IP.IP port 38524


ssh client kicked off immediately after d-bus restart. Higher time 
resolution may be requested by


journalctl -o short-iso-precise

May 05 14:09:14 debzit sshd[14239]: pam_unix(sshd:session): session 
closed for user zithro

May 05 14:09:14 debzit systemd[711]: at-spi-dbus-bus.service: Succeeded.
May 05 14:09:14 debzit lightdm[23289]: pam_unix(lightdm:session): 
session closed for user zithro


Likely it is completion of closing PAM lightdm session. I do not 
remember if it is possible to increase PAM verbosity to get a log entry 
when PAM close session are called. However systemd may perform actions 
in parallel, so attributions of log entries to specific actions may be 
ambiguous.

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Max Nikulin]

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. I am aware of "loginctl enable-linger" and 
of user logout timeout, but I have no reason to experiment with them in 
action yet.


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.


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.

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Max Nikulin]

On 05/05/2023 18:58, zithro wrote:

# loginctl list-sessions
SESSION  UID USER    SEAT  TTY
     111 1000 zithro
     112 1000 zithro
     141 1000 zithro    pts/0


I do not see anything suspicious. I suppose, dbus-user-session 
hypothesis by David may be more productive. Perhaps you may prevent 
killing of applications using "dbus-launch PROGRAM" from ssh sessions, 
but you may need to kill extra D-Bus daemon when the PROGRAM is 
finished. And be prepared that applications may be not ready to multiple 
sessions for the same user.


Frankly speaking, I expected that dbus-user-session should keep daemon 
running till at least one session is alive. It is surprise that logoff 
from desktop session kills d-bus despite other connections.



Does it happen for newly created user with no customization?


Never tried !


I recommended to do it just for a case that you added something to init 
files for the "zithro" user.

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[zithro]

On 05 May 2023 16:10, to...@tuxteam.de wrote:

I have now full logs of before/after GUI logon/logoff, I posted them in the
other post.
Will try to make sense of it with this lead ... after a needed break ^^


I saved that for a look during weekend, now I'm supposed to fix
an update of... forget it :)


Hmmm, don't put my logs on the interwebs ! Wait, what did I do ... Damn 
it, too late ! ;)
Joke aside, that's a nice thing to even think about, even if you don't 
do it in the end.


Happy update fixing then, but would be nice to know what the problem is, 
in case we have it too ?



I don't know whether there's a way to tell the DE to leave the
user session dbus alone when it was already running at start.


Don't even know what you mean, so to do it ... ^^


Too long to explain.
But that might explain also why I dislike that stuff.


The first sentence, damn, that's now two times you do it to me !
(I'm just messing with you, no anger there ;) Even if, to be totally 
honest, as much as this time I totally understand your POV, the 1st time 
I was really disappointed).


I agree about the last sentence though, always KISS ! ^^
(KISS without a comma, for those who know what I'm talking about)

Nicolas Boileau said :

Ce que l’on conçoit bien s’énonce clairement,
Et les mots pour le dire arrivent aisément

[
What we conceive well is clearly stated,
And the words to say it come easily.
  /other translation/
Whatever is well conceived is clearly said,
And the words to say it flow with ease
]

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[tomas]

On Fri, May 05, 2023 at 03:26:12PM +0200, zithro wrote:
> On 05 May 2023 14:11, to...@tuxteam.de wrote:

[...]

> > No DE, just a window manager (fvwm2).
> 
> Isn't that fluxbox ? That's the GUI I used on Slackware.
> Simple, lean, efficient !

No, quite a bit older. Fluxbox 2000-ish, fvwm 199-small-ish.

[...]

> I have now full logs of before/after GUI logon/logoff, I posted them in the
> other post.
> Will try to make sense of it with this lead ... after a needed break ^^

I saved that for a look during weekend, now I'm supposed to fix
an update of... forget it :)

> > I don't know whether there's a way to tell the DE to leave the
> > user session dbus alone when it was already running at start.
> 
> Don't even know what you mean, so to do it ... ^^

Too long to explain. But that might explain also why I dislike
that stuff.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[zithro]

On 05 May 2023 14:11, to...@tuxteam.de wrote:

On Fri, May 05, 2023 at 01:58:55PM +0200, zithro wrote:

On 05 May 2023 06:32, to...@tuxteam.de wrote:

dbus is a candidate. Let me explain: I have a funny setup -- no systemd,
no dbus (still, Debian buster, and X).


I'm on bullseye, I know how to switch back to old init, but have no clue
about Dbus (kinda a Linux-GUI-with-systemd noob).
Which DE/DM you using ? I'm on MATE but also would like to get rid of many
"gvfs-*" stuff. systemctl masking is not enough and filling logs with
errors.


No DE, just a window manager (fvwm2).


Isn't that fluxbox ? That's the GUI I used on Slackware.
Simple, lean, efficient !
Ah, quick search showed me that no, from the derivatives tree image of 
fvwm2 on wikipedia. may be wrong.

But I'm a bit fed up with GUIs right now. Well, systemd rather !
Anyways, back to console fun.




At some point in time, the browser (firefox) brought in dbus via some
dependencies. Annoyed, I killed dbus -- and poof, all browser instances
were gone.


Another thing I might try. But no clue what's the relation between dbus and
firefox. Also, I'm running FF in firejail.


Most applications use it to store their app preferences (just as a
transport to the store backend, typically some gsettings-thingy).
But they may use it to start other applications, etc.

No idea what firefox is messing with it (but it seems to run without
currently, nevertheless).


If I inhibit dbus from starting, the browsers run fine without it. My
hunch is that they keep an open socket conection to the dbus and die
on SIGPIPE or some such.


Again, curious how to get rid of dbus, if it's not really useful.


That depends on your needs. There are some things which will refuse
working right away because dbus is deeply built into how they work
(Bluez, for one: they use dbus like someone else would use a shared
lib). So if you use bluetooth devices, you'll have to make do with
dbus, I fear.


Good to know, another thing to look for ...
But no need for bluetooth on this machine, it's a domU \o/


So yes, if all those apps are sharing "the" session dbus, possibly
started by whoever came first *and* the logout takes the session
dbus down, this might be an explanation.


Again, dunno, after domU boot I usually first login via SSH, and on rare
occasions I login via GUI/VNC, and then ... boom.


One thing you could try is to see whether, after starting one
of those programs which get taken down, the user session dbus
is running (and wasn't before). See what happens when you log
out (does it disappear?).

Then try killing it "by hand" and see whether the same happens.


I have now full logs of before/after GUI logon/logoff, I posted them in 
the other post.

Will try to make sense of it with this lead ... after a needed break ^^


I don't know whether there's a way to tell the DE to leave the
user session dbus alone when it was already running at start.


Don't even know what you mean, so to do it ... ^^


Those DEs behave as if the computer were theirs, not yours ;-)


Aaaand I *hate* that too !


Now don't ask me why I try to avoid that ;-)


If only I knew beforehand ^^


:-)


Not funny ... for me ^^ (joking)



Cheers


Thanks again

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[zithro]

So, previous post was BEFORE logging in into GUI via VNC.
Now, I have outputs from after GUI LOGIN and after GUI LOGOFF.
I've removed the maximum of useless lines (audio, GUI apps, gvfs stuff, 
etc), but tried to keep the most about systemd and dbus, as I'm clueless 
about what you wanna read ...

This post is a facking mess ! Sorry for the "encyclopedia" ...


On 05 May 2023 04:13, Max Nikulin wrote:

Have you inspected journalctl output (as root) around the "log off" moment?



journalctl after GUI LOGIN


May 05 14:04:45 debzit lightdm[23289]: gkr-pam: unable to locate daemon 
control file
May 05 14:04:45 debzit lightdm[23289]: gkr-pam: stashed password to try 
later in open session

May 05 14:04:45 debzit systemd[1]: Stopping Session c2 of user lightdm.
May 05 14:04:45 debzit lightdm[14038]: 
pam_unix(lightdm-greeter:session): session closed for user lightdm

May 05 14:04:45 debzit systemd[1]: session-c2.scope: Succeeded.
May 05 14:04:45 debzit systemd[1]: Stopped Session c2 of user lightdm.
May 05 14:04:45 debzit systemd[1]: session-c2.scope: Consumed 12.947s 
CPU time.
May 05 14:04:45 debzit lightdm[23289]: pam_unix(lightdm:session): 
session opened for user zithro(uid=1000) by (uid=0)

May 05 14:04:45 debzit systemd-logind[480]: Removed session c2.
May 05 14:04:45 debzit systemd-logind[480]: New session 154 of user zithro.
May 05 14:04:45 debzit systemd[1]: Started Session 154 of user zithro.
May 05 14:04:45 debzit rtkit-daemon[479]: Supervising 7 threads of 3 
processes of 1 users.
May 05 14:04:45 debzit pulseaudio[14058]: After module unload, module 
'module-null-sink' was still loaded!

May 05 14:04:45 debzit systemd[14042]: pulseaudio.service: Succeeded.
May 05 14:04:45 debzit dbus-daemon[13960]: [session uid=1000 pid=13960] 
Activating service name='org.freedesktop.portal.IBus' requested by 
':1.23' (uid=1000 pid=23375 comm="/usr/bin/ibus-daemon --daemonize --xim ")
May 05 14:04:45 debzit dbus-daemon[13960]: [session uid=1000 pid=13960] 
Successfully activated service 'org.freedesktop.portal.IBus'
May 05 14:04:45 debzit at-spi-bus-launcher[23376]: dbus-daemon[23376]: 
Activating service name='org.a11y.atspi.Registry' requested by ':1.1' 
(uid=1000 pid=23383 comm="/usr/libexec/ibus-ui-gtk3 ")
May 05 14:04:45 debzit dbus-daemon[13960]: [session uid=1000 pid=13960] 
Activating via systemd: service name='org.freedesktop.portal.Desktop' 
unit='xdg-desktop-portal.service' requested by ':1.31' (uid=1000 
pid=23384 comm="/usr/libexec/ibus-extension-gtk3 ")

May 05 14:04:46 debzit systemd[711]: Starting Portal service...
May 05 14:04:46 debzit at-spi-bus-launcher[23376]: dbus-daemon[23376]: 
Successfully activated service 'org.a11y.atspi.Registry'
May 05 14:04:46 debzit at-spi-bus-launcher[23407]: SpiRegistry daemon is 
running with well-known name - org.a11y.atspi.Registry
May 05 14:04:46 debzit dbus-daemon[13960]: [session uid=1000 pid=13960] 
Activating via systemd: service 
name='org.freedesktop.impl.portal.desktop.gtk' 
unit='xdg-desktop-portal-gtk.service' requested by ':1.33' (uid=1000 
pid=23408 comm="/usr/libexec/xdg-desktop-portal ")
May 05 14:04:46 debzit systemd[711]: Starting Portal service (GTK+/GNOME 
implementation)...
May 05 14:04:46 debzit dbus-daemon[13960]: [session uid=1000 pid=13960] 
Activating service name='ca.desrt.dconf' requested by ':1.34' (uid=1000 
pid=23414 comm="/usr/libexec/xdg-desktop-portal-gtk ")
May 05 14:04:46 debzit dbus-daemon[13960]: [session uid=1000 pid=13960] 
Successfully activated service 'ca.desrt.dconf'
May 05 14:04:46 debzit dbus-daemon[13960]: [session uid=1000 pid=13960] 
Successfully activated service 'org.freedesktop.impl.portal.desktop.gtk'
May 05 14:04:46 debzit systemd[711]: Started Portal service (GTK+/GNOME 
implementation).
May 05 14:04:46 debzit dbus-daemon[13960]: [session uid=1000 pid=13960] 
Activating service name='org.freedesktop.secrets' requested by ':1.33' 
(uid=1000 pid=23408 comm="/usr/libexec/xdg-desktop-portal ")
May 05 14:04:46 debzit dbus-daemon[13960]: [session uid=1000 pid=13960] 
Successfully activated service 'org.freedesktop.secrets'
May 05 14:04:46 debzit dbus-daemon[13960]: [session uid=1000 pid=13960] 
Successfully activated service 'org.freedesktop.portal.Desktop'

May 05 14:04:46 debzit systemd[711]: Started Portal service.
May 05 14:04:46 debzit x-session-manager[23299]: WARNING: Unable to find 
provider '' of required component 'dock'
May 05 14:04:46 debzit gnome-keyring-daemon[23296]: The Secret Service 
was already initialized
May 05 14:04:46 debzit dbus-daemon[471]: [system] Activating via 
systemd: service name='org.freedesktop.hostname1' 
unit='dbus-org.freedesktop.hostname1.service' requested by ':1.186' 
(uid=1000 pid=23468 comm="/usr/bin/mate-settings-daemon ")

May 05 14:04:46 debzit systemd[1]: Starting Hostname Service...
May 05 14:04:46 debzit dbus-daemon[471]: [system] Su

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[tomas]

On Fri, May 05, 2023 at 01:58:55PM +0200, zithro wrote:
> On 05 May 2023 06:32, to...@tuxteam.de wrote:
> > dbus is a candidate. Let me explain: I have a funny setup -- no systemd,
> > no dbus (still, Debian buster, and X).
> 
> I'm on bullseye, I know how to switch back to old init, but have no clue
> about Dbus (kinda a Linux-GUI-with-systemd noob).
> Which DE/DM you using ? I'm on MATE but also would like to get rid of many
> "gvfs-*" stuff. systemctl masking is not enough and filling logs with
> errors.

No DE, just a window manager (fvwm2).

> > At some point in time, the browser (firefox) brought in dbus via some
> > dependencies. Annoyed, I killed dbus -- and poof, all browser instances
> > were gone.
> 
> Another thing I might try. But no clue what's the relation between dbus and
> firefox. Also, I'm running FF in firejail.

Most applications use it to store their app preferences (just as a
transport to the store backend, typically some gsettings-thingy).
But they may use it to start other applications, etc.

No idea what firefox is messing with it (but it seems to run without
currently, nevertheless).

> > If I inhibit dbus from starting, the browsers run fine without it. My
> > hunch is that they keep an open socket conection to the dbus and die
> > on SIGPIPE or some such.
> 
> Again, curious how to get rid of dbus, if it's not really useful.

That depends on your needs. There are some things which will refuse
working right away because dbus is deeply built into how they work
(Bluez, for one: they use dbus like someone else would use a shared
lib). So if you use bluetooth devices, you'll have to make do with
dbus, I fear.

> > So yes, if all those apps are sharing "the" session dbus, possibly
> > started by whoever came first *and* the logout takes the session
> > dbus down, this might be an explanation.
> 
> Again, dunno, after domU boot I usually first login via SSH, and on rare
> occasions I login via GUI/VNC, and then ... boom.

One thing you could try is to see whether, after starting one
of those programs which get taken down, the user session dbus
is running (and wasn't before). See what happens when you log
out (does it disappear?).

Then try killing it "by hand" and see whether the same happens.

I don't know whether there's a way to tell the DE to leave the
user session dbus alone when it was already running at start.
Those DEs behave as if the computer were theirs, not yours ;-)

> > Now don't ask me why I try to avoid that ;-)
> 
> If only I knew beforehand ^^

:-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[zithro]

On 05 May 2023 07:33, David wrote:

On Thu, 4 May 2023 at 19:07, zithro  wrote:


this is a rather strange problem, I hope the title is explicit enough.


Subject: Logging off an X session closes all ssh -X connections
started previously from outside X


Yeah, I meant title==subject, I was hoping it was clear enough for everyone.
Why did you copy it ? ^^



That sounds like what is documented here, with the solution at the end:

$ apt show dbus-user-session
Package: dbus-user-session
Version: 1.12.24-0+deb11u1
[... some output snipped for brevity ...]
Description: simple interprocess messaging system (systemd --user integration)
  D-Bus is a message bus, used for sending messages between applications.
  Conceptually, it fits somewhere in between raw sockets and CORBA in
  terms of complexity.
  .
  On systemd systems, this package opts in to the session model in which
  a user's session starts the first time they log in, and does not end
  until all their login sessions have ended. This model merges all
  parallel non-graphical login sessions (text mode, ssh, cron, etc.), and up
  to one graphical session, into a single "user-session" or "super-session"
  within which all background D-Bus services are shared.
  .
  Multiple graphical sessions per user are not currently supported in this
  mode; as a result, it is particularly suitable for gdm, which responds to
  requests to open a parallel graphical session by switching to the existing
  graphical session and unlocking it.
  .
  To retain dbus' traditional session semantics, in which login sessions
  are artificially isolated from each other, remove this package and install
  dbus-x11 instead.
  [...]



Will keep that under the elbow, but it *seems* a systemd problem (see 
other posts, like the ycombinator link, first post is exactly my problem).


Thanks

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[zithro]

On 05 May 2023 06:32, to...@tuxteam.de wrote:

dbus is a candidate. Let me explain: I have a funny setup -- no systemd,
no dbus (still, Debian buster, and X).


I'm on bullseye, I know how to switch back to old init, but have no clue 
about Dbus (kinda a Linux-GUI-with-systemd noob).
Which DE/DM you using ? I'm on MATE but also would like to get rid of 
many "gvfs-*" stuff. systemctl masking is not enough and filling logs 
with errors.




At some point in time, the browser (firefox) brought in dbus via some
dependencies. Annoyed, I killed dbus -- and poof, all browser instances
were gone.


Another thing I might try. But no clue what's the relation between dbus 
and firefox. Also, I'm running FF in firejail.



If I inhibit dbus from starting, the browsers run fine without it. My
hunch is that they keep an open socket conection to the dbus and die
on SIGPIPE or some such.


Again, curious how to get rid of dbus, if it's not really useful.


So yes, if all those apps are sharing "the" session dbus, possibly
started by whoever came first *and* the logout takes the session
dbus down, this might be an explanation.


Again, dunno, after domU boot I usually first login via SSH, and on rare 
occasions I login via GUI/VNC, and then ... boom.




Now don't ask me why I try to avoid that ;-)


If only I knew beforehand ^^



Cheers


Thanks

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[zithro]

On 05 May 2023 05:30, David Wright wrote:

Isn't it this issue?

https://news.ycombinator.com/item?id=19023885


Looks like it, yes !



I'm afraid I can't replicate the problem, though, as I don't have
a "log off" button or menu entry. That might suggest that the
problem is in something I don't run, like the DE or DM. (I assume
we're all using systemd.)


Yes, I'm using systemd.



When I run multiple jobs through multiple ssh commands, I find
they're in different scopes, eg:

0::/user.slice/user-1000.slice/session-229.scope
0::/user.slice/user-1000.slice/session-230.scope

(To see the slice and scope, add cgroup to your ps command.
Add it as the last option, or its output might get truncated.)

When you've logged in to X, what slice/scopes do you see for X and
the processes you previously started? Are they all the same?


I've posted the results of this in the reply to Max Nikulin along the 
others commands he told me to run.

But yeah they run as different scopes.



I think I've read that the way to get round this (or "go with the
flow") is to run the earlier processes as user services under systemd,
but I've not tried it.


I'm a systemd noob, don't really know what you talking about ^^
Better switch to a better init system, I still fail to see how systemd 
is helping me, I only had problems with it.

I'm a long time Slackware user, so I can compare inits. /rant off



Cheers,
David.



Thanks

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[zithro]

On 05 May 2023 04:13, 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) !


Have you inspected journalctl output (as root) around the "log off" moment?


Will do, but it's such a PITA ...

A wild guess is that it might be force close of systemd user session, 
however it should not happen. Try to compare systemd-cgls (user .slice 
and .scope), "loginctl list-users", "loginctl list-sessions" on each step.


I'm a systemd noob, don't really know what you talking about ^^
But seems like the culprit.
Ran those commands (fucking auto pager though, way to break scrolling 
... another fail)


So *before* logging in X via VNC :

# systemd-cgls --no-pager
Control group /:
-.slice
├─user.slice
│ ├─user-112.slice
│ │ ├─session-c2.scope
│ │ │ ├─14038 lightdm --session-child 16 19
│ │ │ └─14060 /usr/sbin/lightdm-gtk-greeter
│ │ └─user@112.service …
│ │   ├─app.slice
 [snipped unrelated]
│ │   │ ├─at-spi-dbus-bus.service
│ │   │ │ ├─14078 /usr/libexec/at-spi-bus-launcher
│ │   │ │ ├─14083 /usr/bin/dbus-daemon 
--config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork 
--print-addr…

│ │   │ │ └─14102 /usr/libexec/at-spi2-registryd --use-gnome-session
│ │   │ └─dbus.service
│ │   │   └─14061 /usr/bin/dbus-daemon --session --address=systemd: 
--nofork --nopidfile --systemd-activation --syslog-on…

│ │   └─init.scope
│ │ ├─14042 /lib/systemd/systemd --user
│ │ └─14043 (sd-pam)
│ ├─user-0.slice
│ │ ├─session-147.scope
│ │ │ ├─22477 sshd: root@pts/2
│ │ │ ├─22483 -bash
│ │ │ └─22725 systemd-cgls --no-pager
│ │ ├─session-148.scope
│ │ │ ├─22495 sshd: root@pts/3
│ │ │ ├─22501 -bash
│ │ │ └─22521 htop
│ │ ├─session-151.scope
│ │ │ ├─22645 sshd: root@pts/5
│ │ │ └─22651 -bash
│ │ ├─session-145.scope
│ │ │ ├─22440 sshd: root@pts/1
│ │ │ ├─22462 -bash
│ │ │ └─22634 journalctl --no-pager -b 0 --follow
│ │ └─user@0.service …
│ │   └─init.scope
│ │ ├─22443 /lib/systemd/systemd --user
│ │ └─22444 (sd-pam)
│ └─user-1000.slice
│   ├─user@1000.service …
│   │ ├─app.slice
│   │ │ ├─xdg-permission-store.service
│   │ │ │ └─14334 /usr/libexec/xdg-permission-store
│   │ │ ├─xdg-document-portal.service
│   │ │ │ ├─14331 /usr/libexec/xdg-document-portal
│   │ │ │ └─14339 fusermount -o 
rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal -- 
/run/user/1000/doc

│   │ │ ├─pulseaudio.service
│   │ │ │ └─14031 /usr/bin/pulseaudio --daemonize=no --log-target=journal
│   │ │ ├─gvfs-daemon.service
│   │ │ │ └─14302 /usr/libexec/gvfsd
│   │ │ ├─at-spi-dbus-bus.service
│   │ │ │ └─14508 /usr/libexec/at-spi-bus-launcher
│   │ │ ├─pipewire.service
│   │ │ │ ├─752 /usr/bin/pipewire
│   │ │ │ └─756 /usr/bin/pipewire-media-session
│   │ │ └─dbus.service
│   │ │   └─13960 /usr/bin/dbus-daemon --session --address=systemd: 
--nofork --nopidfile --systemd-activation --syslog-on…

│   │ └─init.scope
│   │   ├─711 /lib/systemd/systemd --user
│   │   └─724 (sd-pam)
│   ├─session-111.scope
│   │ ├─14107 sshd: zithro [priv]
│   │ ├─14113 sshd: zithro@notty
│   │ ├─14114 firejail firefox -p junk -no-remote
│   │ ├─14117 /usr/bin/xdg-dbus-proxy --fd=4 --args=5
│   │ ├─14119 firejail firefox -p junk -no-remote
│   │ ├─14128 firefox-esr -p junk -no-remote
 [snipped all threads]
│   ├─session-141.scope
│   │ ├─21925 sshd: zithro [priv]
│   │ ├─21931 sshd: zithro@pts/0
│   │ └─21932 ssh zithro@otherhost
│   ├─session-112.scope
│   │ ├─14239 sshd: zithro [priv]
│   │ ├─14246 sshd: zithro@notty
│   │ ├─14247 firejail thunderbird
│   │ ├─14250 firejail thunderbird
│   │ ├─14259 /usr/lib/thunderbird/thunderbird
│   └─session-149.scope
│ ├─22606 sshd: zithro [priv]
│ ├─22612 sshd: zithro@pts/4
│ └─22613 -bash
├─init.scope
│ └─1 /sbin/init
└─system.slice
  ├─dbus.service
  │ └─471 /usr/bin/dbus-daemon --system --address=systemd: --nofork 
--nopidfile --systemd-activation --syslog-only

 [snipped rest of slice]

# loginctl list-sessions
SESSION  UID USERSEAT  TTY
111 1000 zithro
112 1000 zithro
141 1000 zithropts/0
1450 root
1470 root
1480 root
149 1000 zithropts/4
1510 root
 c2  112 lightdm seat0

9 sessions listed.

# loginctl list-users
 UID USER
   0 root
 112 lightdm
1000 zithro

3 users listed.


To keep this answer humanly readable, I will post the results of 
previous commands after GUI login and after GUI logoff in another answer ...



Perhaps it may be related to user D-Bus sessions, however I would expect 
that ssh GUI app has its own bus created by dbus-launch.


Dunno exactly how to report this. In the firefox firejail there's 
"xdg-dbus-proxy", but not in the thunderbird firejail.


# ps -eo pid,user,args,cgroup | grep -i dbus
471 message+ /usr/bin/dbus-daemon --syst 0::/system.slice/dbus.servic

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[David]

On Thu, 4 May 2023 at 19:07, zithro  wrote:

> this is a rather strange problem, I hope the title is explicit enough.

Subject: Logging off an X session closes all ssh -X connections
started previously from outside X

> Here is what happens chronologically :
>
> 1. I start various SSH connections to a host, some normal, some with X
> forwarding, like that: "ssh user@host" and "ssh -X -n user@host GUI_APP"
> (like firejail firefox, firejail thunderbird, etc). There's no user
> connected under X yet, only the greeter is displayed.
>
> 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) !
>
> Everything is done using the same local and remote users (same UID but
> different names). sshd is the parent process of all my remote SSH sessions.
>
> I don't get how apps and shells NOT started via the X session, moreover
> previously to its creation, are closed when the X session closes, what's
> happening here ?!

> As the outcome is the same with VNC and rdesktop, I guess the problem is
> lying in the OS. Could it be related to logind ? Or an SSH(d) setting ?

That sounds like what is documented here, with the solution at the end:

$ apt show dbus-user-session
Package: dbus-user-session
Version: 1.12.24-0+deb11u1
[... some output snipped for brevity ...]
Description: simple interprocess messaging system (systemd --user integration)
 D-Bus is a message bus, used for sending messages between applications.
 Conceptually, it fits somewhere in between raw sockets and CORBA in
 terms of complexity.
 .
 On systemd systems, this package opts in to the session model in which
 a user's session starts the first time they log in, and does not end
 until all their login sessions have ended. This model merges all
 parallel non-graphical login sessions (text mode, ssh, cron, etc.), and up
 to one graphical session, into a single "user-session" or "super-session"
 within which all background D-Bus services are shared.
 .
 Multiple graphical sessions per user are not currently supported in this
 mode; as a result, it is particularly suitable for gdm, which responds to
 requests to open a parallel graphical session by switching to the existing
 graphical session and unlocking it.
 .
 To retain dbus' traditional session semantics, in which login sessions
 are artificially isolated from each other, remove this package and install
 dbus-x11 instead.
 [...]

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[tomas]

On Fri, May 05, 2023 at 09:13:04AM +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.

[...]

> Perhaps it may be related to user D-Bus sessions, however I would expect
> that ssh GUI app has its own bus created by dbus-launch.

dbus is a candidate. Let me explain: I have a funny setup -- no systemd,
no dbus (still, Debian buster, and X).

At some point in time, the browser (firefox) brought in dbus via some
dependencies. Annoyed, I killed dbus -- and poof, all browser instances
were gone.

If I inhibit dbus from starting, the browsers run fine without it. My
hunch is that they keep an open socket conection to the dbus and die
on SIGPIPE or some such.

So yes, if all those apps are sharing "the" session dbus, possibly
started by whoever came first *and* the logout takes the session
dbus down, this might be an explanation.

Now don't ask me why I try to avoid that ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[David Wright]

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) !
> 
> Have you inspected journalctl output (as root) around the "log off" moment?
> 
> A wild guess is that it might be force close of systemd user session,
> however it should not happen. Try to compare systemd-cgls (user .slice
> and .scope), "loginctl list-users", "loginctl list-sessions" on each
> step.
> 
> Perhaps it may be related to user D-Bus sessions, however I would
> expect that ssh GUI app has its own bus created by dbus-launch.
> 
> Does it happen for newly created user with no customization?

Isn't it this issue?

https://news.ycombinator.com/item?id=19023885

I'm afraid I can't replicate the problem, though, as I don't have
a "log off" button or menu entry. That might suggest that the
problem is in something I don't run, like the DE or DM. (I assume
we're all using systemd.)

When I run multiple jobs through multiple ssh commands, I find
they're in different scopes, eg:

0::/user.slice/user-1000.slice/session-229.scope
0::/user.slice/user-1000.slice/session-230.scope

(To see the slice and scope, add cgroup to your ps command.
Add it as the last option, or its output might get truncated.)

When you've logged in to X, what slice/scopes do you see for X and
the processes you previously started? Are they all the same?

I think I've read that the way to get round this (or "go with the
flow") is to run the earlier processes as user services under systemd,
but I've not tried it.

Cheers,
David.

Re: Logging off an X session closes all ssh -X connections started previously from outside X

[Max Nikulin]

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) !


Have you inspected journalctl output (as root) around the "log off" moment?

A wild guess is that it might be force close of systemd user session, 
however it should not happen. Try to compare systemd-cgls (user .slice 
and .scope), "loginctl list-users", "loginctl list-sessions" on each step.


Perhaps it may be related to user D-Bus sessions, however I would expect 
that ssh GUI app has its own bus created by dbus-launch.


Does it happen for newly created user with no customization?