GNOME Bugzilla – Bug 777772
gnome-terminal stops working after started VNC server
Last modified: 2017-02-09 07:35:21 UTC
Steps to reproduce: 1 boot up 2 login to gnome 3 launch gnome-terminal(everything works well now) 4 start vnc session by running cmd: vncserver (provided by tigervnc-server) 5 close gnome-terminal 6 launch gnome-terminal again, problem occurs. 7 run vncserver -kill :1 in this problematic gnome terminal, the terminal will go away with the VNC session as if the terminal belongs to the VNC session instead of the local session When problem occurs, gnome-terminal's menu doesn't respond, e.g. if I click Help->about, nothing happens etc. And the copy/paster functionality is also lost. This problem is true for both Fedora 24 and 25 which ships GNOME with 3.20 and 3.22.
Please compare the environment of the gnome-terminal-server processes started in step 3 and 6: $ strings /proc/$(pidof gnome-terminal-server)/environ | sort and the diff -u.
At home now and didn't have access to my Fedora desktop. But I managed to boot a Fedora 24 livecd and reproduced the issue. Here is the diff: aaron@localhost:~$ diff -u 3 6 --- 3 2017-01-26 23:15:49.847835529 +0800 +++ 6 2017-01-26 23:15:49.847835529 +0800 @@ -1,5 +1,5 @@ DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus -DISPLAY=:0 +DISPLAY=:1 GNOME_DESKTOP_SESSION_ID=this-is-deprecated HOME=/home/liveuser LANG=en_US.UTF-8
So starting vncserver alters the dbus activation environment of the dbus session bus that belongs to :0 (gnome session, I guess). It has no business doing that. -> vncserver bug The rest of the symptoms are probably just that there's no settings demon running for :1, or no window manager, etc.
Thanks for the quick response, I have filed a issue for tigervnc: https://github.com/TigerVNC/tigervnc/issues/407 One thing I do not understand is, why only gnome-terminal gets affected? Other GNOME apps like nautilus, still has the DISPLAY environ variable set to 0 after vncserver started.
One more information, I just realized the tigervnc-server package is also updated to 1.7.x(almost the latest) on Fedora 23 during its lifetime but gnome-terminal doesn't have this problem there.
gnome-terminal-server exits when the last window is closed; nautilus never exits as long as the gnome-session lasts.
Maybe I didn't make it clear - I didn't start nautilus before starting vncserver but only after and still, nautilus's DISPLAY environment variable is 0, instead of 1.
Starting gnome-terminal in step 6 from xterm like the below steps could work around the problem: [aaron@localhost ~]$ /usr/libexec/gnome-terminal-server & [1] 18138 [aaron@localhost src]$ gnome-terminal No idea what happened though.
(In reply to Christian Persch from comment #6) > gnome-terminal-server exits when the last window is closed; nautilus never > exits as long as the gnome-session lasts. Minor nitpick: unless you are using icons on the desktop, nautilus waits for a few seconds after the last window was closed before exiting.
(In reply to Debarshi Ray from comment #9) > Minor nitpick: unless you are using icons on the desktop, nautilus waits for I do not use icons on the desktop. > a few seconds after the last window was closed before exiting. And I have verified nautilus is not there with: ps ax |grep nautilus
I happen to "fix" this problem today by changing my .vnc/xstartup file: [aaron@aaronlu .vnc]$ diff -u xstartup.orig xstartup --- xstartup.orig 2017-02-03 10:23:42.322160908 +0800 +++ xstartup 2017-02-09 15:19:34.258713703 +0800 @@ -2,4 +2,4 @@ unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS -exec /etc/X11/xinit/xinitrc +exec gnome-session It turned out the /etc/X11/xinit/xinitrc will execute /etc/X11/xinit/xinitrc-common, which again will execute all scripts in /etc/X11/xinit/xinitrc.d, where there is a script called 50-systemd-user.sh: [aaron@aaronlu xinitrc.d]$ cat 50-systemd-user.sh #!/bin/sh systemctl --user import-environment DISPLAY XAUTHORITY if which dbus-update-activation-environment >/dev/null 2>&1; then dbus-update-activation-environment DISPLAY XAUTHORITY fi Commenting out the first line before launching vnc session is enough to solve the problem here, I guess the reason is: When the vncsession is launched, the DISPLAY is set to :1 and gets propagated to my local gnome session and that affected gnome-terminal. But I know very little about these things so this could very well be wrong. The systemd developer seems to determine a user can't be running two graphic sessions at the same time: http://systemd-devel.freedesktop.narkive.com/F7V6SZSk/using-systemd-user-to-manage-graphical-sessions " AFAIK, the general idea of --user is that there's at most one graphical session (per user) at a time, so things like $DISPLAY naturally become per user. " So the proper fix here seems to be fixing the automatically generated vnc xstartup script. Thanks for your time, it's indeed not a gnome-terminal bug.