SSH Session where TVNC was started blocks automatic suspend
Felix Natter
Dear turbovnc experts,
our home office use case is that people log in via ssh over vpn,
start vncserver from there and then connect via tvnc, and
we are using an automated suspend-to-ram solution that relies on
logind sessions not blocking it.
When starting TVNC from ssh and then logging out of the ssh
session,
a State: closing session is left behind which blocks suspend:
$ loginctl
SESSION UID USER SEAT TTY
[..]
85 1000043 USER pts/1
[..]
$ loginctl session-status 85
85 - USER (UID)
Since: Tue 2025-01-07 12:55:19 CET; 1 day 18h ago
Leader: 178770
TTY: pts/1
Remote: 172.16.0.1
Service: sshd; type tty; class user
State: closing
Unit: session-85.scope
├─179044 /opt/TurboVNC/bin/Xvnc :3 -desktop
"TurboVNC: sidact36:3 (USER)" -auth /home/USER/.Xauthority
-geometry 1240x900 -depth 24 -rfbauth /home/USER/.vnc/passwd
-x509cert /home/USER/.vnc/x509_cert.pem -x509key /h>
├─179049 sh -c
"(/opt/TurboVNC/bin/xstartup.turbovnc; /opt/TurboVNC/bin/vncserver
-kill :3) >> '/home/USER/.vnc/sidact36:3.log' 2>&1
&"
├─179050 mate-session
├─179054 /usr/bin/dbus-launch --sh-syntax
--exit-with-session
├─179055 /usr/bin/dbus-daemon --syslog --fork
--print-pid 6 --print-address 8 --session
├─179151 /usr/bin/ssh-agent /usr/bin/im-launch
mate-session
├─179168 /usr/bin/ibus-daemon --daemonize --xim
├─179172 /usr/libexec/gvfsd
├─179177 /usr/libexec/gvfsd-fuse
/run/user/1000043/gvfs -f
├─179182 /usr/libexec/ibus-dconf
├─179183 /usr/libexec/ibus-ui-gtk3
├─179185 /usr/libexec/ibus-extension-gtk3
├─179187 /usr/libexec/ibus-x11 --kill-daemon
├─179194 /usr/libexec/ibus-portal
├─179215 /usr/libexec/at-spi-bus-launcher
├─179220 /usr/bin/dbus-daemon
--config-file=/usr/share/defaults/at-spi2/accessibility.conf
--nofork --print-address 13
--address=unix:path=/run/user/1000043/at-spi/bus_3
├─179225 /usr/libexec/at-spi2-registryd
--use-gnome-session
├─179233 /usr/libexec/xdg-desktop-portal
├─179247 /usr/libexec/xdg-permission-store
├─179258 /usr/libexec/xdg-desktop-portal-gnome
├─179262 /usr/libexec/ibus-engine-simple
├─179367 sh -c
"/usr/lib/x86_64-linux-gnu/libproxy/0.4.17/pxgsettings
org.gnome.system.proxy org.gnome.system.proxy.http
org.gnome.system.proxy.https org.gnome.system.proxy.ftp
org.gnome.system.proxy.socks"
├─179368
/usr/lib/x86_64-linux-gnu/libproxy/0.4.17/pxgsettings
org.gnome.system.proxy org.gnome.system.proxy.http
org.gnome.system.proxy.https org.gnome.system.proxy.ftp
org.gnome.system.proxy.socks
├─179373 /usr/libexec/xdg-desktop-portal-gtk
├─179425 /usr/libexec/dconf-service
├─179431 /usr/bin/gnome-keyring-daemon --start
--foreground --components=secrets
├─179441 /usr/bin/mate-settings-daemon
├─179495 /usr/bin/mate-screensaver --no-daemon
├─179504 marco
├─179514 mate-panel
├─179539 /usr/bin/caja
├─179541
/usr/libexec/gvfs-udisks2-volume-monitor
├─179545 /usr/lib/mate-panel/wnck-applet
├─179547 /usr/lib/mate-applets/trashapplet
├─179549
/usr/lib/x86_64-linux-gnu/brisk-menu/brisk-menu
├─179552
/usr/lib/mate-indicator-applet/mate-indicator-applet-complete
├─179555
/usr/lib/mate-panel/notification-area-applet
├─179577 /usr/libexec/gvfs-goa-volume-monitor
├─179581 /usr/libexec/goa-daemon
├─179589
/usr/libexec/ayatana-indicator-application/ayatana-indicator-application-service
├─179593
/usr/libexec/evolution-data-server/evolution-alarm-notify
├─179594 /usr/libexec/gvfsd-trash --spawner :1.5
/org/gtk/gvfs/exec_spaw/0
├─179595
/usr/libexec/ayatana-indicator-messages/ayatana-indicator-messages-service
├─179607
/usr/libexec/ayatana-indicator-power/ayatana-indicator-power-service
├─179617 /usr/libexec/goa-identity-service
├─179633 /usr/libexec/gvfs-afc-volume-monitor
├─179634 update-notifier
├─179636 /usr/libexec/gvfsd-metadata
├─179648 /usr/bin/python3
/usr/bin/blueman-applet
├─179657
/usr/libexec/gvfs-gphoto2-volume-monitor
It can easily be reproduced:
- ssh hostname # hostname of local computer
- /opt/TurboVNC/bin/vncserver -wm mate :2
- log out the ssh session
- the session is not logged out (State: closing)
- the session is properly closed when killing the vnc server
I guess the session is necessary for TVNC to stay running(?), but
can you think of a workaround for
this blocking behavior?
Many Thanks and Best Regards!
Felix
SIDACT GmbH
Simulation Data Analysis and
Compression Technologies
Felix Natter
Software Developer
Auguststraße 29
53229 Bonn
Germany
| Phone | : +49 228 5348 0430 |
| Direct | : +49 228 4097 7118 |
| : felix....@sidact.com | |
| Web | : http://www.sidact.com/ |
Felix Natter
hello turbovnc experts,
I found one workaround (when starting TVNC from ssh session):
systemd-run --scope --user /opt/TurboVNC/bin/vncserver -wm mate :2
A first test was successful, but this has yet to be tested
extensively.
Or can you think of a better solution (I think I have experienced
that when
running the above command from a physical session that the TVNC
process
sometimes was killed on logut..)?
Many Thanks and Best Regards,
Felix
--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/c9005453-5fcd-48f4-9a47-75231326fef8%40sidact.com.
DRC
We were already discussing that in another thread:
https://groups.google.com/g/turbovnc-users/c/jl2y3NmEfsI/m/AaQ3ns_nAgAJ
Also, I am the only TurboVNC maintainer and the only full-time developer. There are no other experts.
Referring to my reply in the other thread, my observation is that:
- A logind session will be associated with
a TurboVNC session when a client connects using SSH tunneling,
and that logind session will go away when the client
disconnects.
- If a TurboVNC session is started via the TurboVNC Session Manager, then an additional logind session will be associated with the TurboVNC session and will persist for the life of the session. However, that logind session will be in the Closing state.
I will experiment with the workaround and
see how it changes the observations. Please be patient, as I am
working on about five things at once.
DRC
To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/65d89397-2e7b-44a7-a664-3b815cd60834%40sidact.com.
Felix Natter
yes, I know you are the only one. Many thanks for all the support
you provide to us!
I apologize for forgetting about the reply in the other thread.
Regarding
systemd-run --scope --user /opt/TurboVNC/bin/vncserver -wm mate :1
For me (Ubuntu 22.04, Mate desktop, turbovnc 3.1.1) this makes the
(physical) session crash on logout!
Due to this and other bugs in systemd & co (maybe even with TVNC?),
my supervisor and I decided to drop systemd-logind suspend and just
use manual suspend.
> I will experiment with the workaround and see how it changes the observations.
> Please be patient, as I am working on about five things at once.
we move to Ubuntu 24 or even 26.
For the record: A workaround using tmux works (with basic testing):
Create (user) cron job:
@reboot /usr/bin/tmux new-session -d -s vnc /bin/bash
then when logged in via ssh, connect to tmux:vnc and start TVNC from there,
and detach from tmux. This avoids the blocking ssh session. Needless
to say, this is a hack.
DRC
In my testing, when I start the TurboVNC Server using 'systemd-run --scope --user', it still doesn't create an additional logind session. Thus, that approach doesn't seem to be fruitful. My understanding is that, whenever you bring systemd into the picture, you forego the ability to have multiple simultaneous sessions (including a simultaneous VNC session and local session.) So it doesn't surprise me that starting the TurboVNC Server with systemd-run interferes with the local session.
I'm afraid that that's the limit of what I
can do for now. It could potentially take weeks of full-time
work to dig into the issue, I can't afford to do that for free,
and no one is going to pay me for it with no guarantee of
success. The only solution I am aware of would be to adopt
TigerVNC's startup mechanism as an optional feature, which would
introduce the limitations I mentioned previously. They have
basically opted to do things the systemd way and accept the
limitations. I have basically opted to do things my way and
deal with the quirks. This is one of those quirks.
DRC
--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.