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
Email : felix.nat...@sidact.com
Web : http://www.sidact.com/
--
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-users+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/turbovnc-users/c9005453-5fcd-48f4-9a47-75231326fef8%40sidact.com.
