This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 959941 - gnome-shell fails to start under ThinLinc (Xvnc)
gnome-shell fails to start under ThinLinc (Xvnc)
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Owen Taylor
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 896648
  Show dependency treegraph
 
Reported: 2013-05-06 05:24 EDT by Pierre Ossman
Modified: 2015-02-17 11:18 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 10:10:00 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Pierre Ossman 2013-05-06 05:24:54 EDT
I'm greeted by an empty desktop when trying to run Gnome 3 under ThinLinc (a VNC server). Fedora 18 works fine though, so this is a regression.

This is what I have in the log:

Executing command for profile gnome-3: gnome-session --session=gnome
GNOME_KEYRING_CONTROL=/home/tltest/.cache/keyring-22EthQ
GPG_AGENT_INFO=/home/tltest/.cache/keyring-22EthQ/gpg:0:1
GNOME_KEYRING_PID=1790
GNOME_KEYRING_CONTROL=/home/tltest/.cache/keyring-22EthQ
GPG_AGENT_INFO=/home/tltest/.cache/keyring-22EthQ/gpg:0:1
GNOME_KEYRING_CONTROL=/home/tltest/.cache/keyring-22EthQ
GPG_AGENT_INFO=/home/tltest/.cache/keyring-22EthQ/gpg:0:1
SSH_AUTH_SOCK=/home/tltest/.cache/keyring-22EthQ/ssh
GNOME_KEYRING_CONTROL=/home/tltest/.cache/keyring-22EthQ
GPG_AGENT_INFO=/home/tltest/.cache/keyring-22EthQ/gpg:0:1
SSH_AUTH_SOCK=/home/tltest/.cache/keyring-22EthQ/ssh
N: [pulseaudio] main.c: User-configured server at 127.0.0.1:4915, refusing to start/autospawn.
Failure: Module initialization failed

(gnome-settings-daemon:1805): power-plugin-WARNING **: failed to turn the panel on: Display is not DPMS capable

(gnome-settings-daemon:1805): power-plugin-WARNING **: Unable to inhibit lid switch: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Operation not permitted

(gnome-settings-daemon:1805): media-keys-plugin-WARNING **: Unable to inhibit keypresses: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Operation not permitted

(gnome-settings-daemon:1805): color-plugin-WARNING **: failed to get edid: unable to get EDID for output

(gnome-settings-daemon:1805): color-plugin-WARNING **: failed to create device: failed to obtain org.freedesktop.color-manager.create-device auth

(gnome-settings-daemon:1805): PackageKit-WARNING **: failed to set proxy: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_5fengine_5ferror.Code3: failed to obtain auth

(gnome-settings-daemon:1805): updates-plugin-WARNING **: failed to set proxies: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_5fengine_5ferror.Code3: failed to obtain auth

(gnome-settings-daemon:1805): color-plugin-WARNING **: no xrandr-default device found: Failed to find output xrandr-default
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Compat map for group 2 redefined
>                   Using new definition
> Warning:          Compat map for group 3 redefined
>                   Using new definition
> Warning:          Compat map for group 4 redefined
>                   Using new definition
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Compat map for group 2 redefined
>                   Using new definition
> Warning:          Compat map for group 3 redefined
>                   Using new definition
> Warning:          Compat map for group 4 redefined
>                   Using new definition
Errors from xkbcomp are not fatal to the X server
    JS ERROR: !!!   Exception in callback for signal: sessions-loaded
    JS ERROR: !!!     message = '"Argument 'string' (type utf8) may not be null"'
    JS ERROR: !!!     fileName = '"/usr/share/gjs-1.0/overrides/GLib.js"'
    JS ERROR: !!!     lineNumber = '105'
    JS ERROR: !!!     stack = '"_pack_variant([object Array],null)@/usr/share/gjs-1.0/overrides/GLib.js:105
_pack_variant([object Array],[object Array])@/usr/share/gjs-1.0/overrides/GLib.js:152
("(s)",[object Array])@/usr/share/gjs-1.0/overrides/GLib.js:262
_proxyInvoker("GetSession",false,[object Array],[object Array])@/usr/share/gjs-1.0/overrides/Gio.js:79
(null,function () {[native code]})@/usr/share/gjs-1.0/overrides/Gio.js:125
(function () {[native code]})@/usr/share/gnome-shell/js/misc/loginManager.js:150
wrapper(function () {[native code]})@/usr/share/gjs-1.0/lang.js:213
()@/usr/share/gnome-shell/js/ui/screenShield.js:516
wrapper()@/usr/share/gjs-1.0/lang.js:213
()@/usr/share/gjs-1.0/lang.js:154
()@/usr/share/gjs-1.0/lang.js:248
_initializeUI()@/usr/share/gnome-shell/js/ui/main.js:148
_sessionsLoaded([object Object])@/usr/share/gnome-shell/js/ui/main.js:109
_emit("sessions-loaded")@/usr/share/gjs-1.0/signals.js:124
([object Object])@/usr/share/gnome-shell/js/ui/sessionMode.js:171
done()@/usr/share/gnome-shell/js/misc/fileUtils.js:33
([object GObject_Object],[object GObject_Object])@/usr/share/gnome-shell/js/misc/fileUtils.js:43
"'

(gnome-shell:1850): GLib-GIO-WARNING **: Type of return value is incorrect: expected `(b)', got `()''
gnome-session[1754]: WARNING: Application 'gnome-shell.desktop' failed to register before timeout
Failed to play sound: File or data not found
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Compat map for group 2 redefined
>                   Using new definition
> Warning:          Compat map for group 3 redefined
>                   Using new definition
> Warning:          Compat map for group 4 redefined
>                   Using new definition
Errors from xkbcomp are not fatal to the X server

** (nm-applet:1941): WARNING **: Could not initialize NMClient /org/freedesktop/NetworkManager: Rejected send message, 3 matched rules; type="method_call", sender=":1.69" (uid=1001 pid=1941 comm="nm-applet ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination="org.freedesktop.NetworkManager" (uid=0 pid=510 comm="/usr/sbin/NetworkManager --no-daemon ")
** Message: applet now removed from the notification area

** (gnome-initial-setup:1953): WARNING **: Could not initialize NMClient /org/freedesktop/NetworkManager: Rejected send message, 3 matched rules; type="method_call", sender=":1.74" (uid=1001 pid=1953 comm="/usr/libexec/gnome-initial-setup ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination="org.freedesktop.NetworkManager" (uid=0 pid=510 comm="/usr/sbin/NetworkManager --no-daemon ")

** (nm-applet:1941): WARNING **: Could not find ShellVersion property on org.gnome.Shell after 5 tries
Comment 1 Pierre Ossman 2013-05-06 05:30:19 EDT
The gnome-shell process is still alive after this though:

tltest    1754  0.0  0.2 744024  2920 ?        Sl   11:19   0:00                  \_ gnome-session --session=gnome
tltest    1805  0.1  0.5 950228  5992 ?        Sl   11:19   0:01                      \_ /usr/libexec/gnome-settings-daemon
tltest    1850  0.3  4.9 1151976 50012 ?       Sl   11:19   0:01                      \_ /usr/bin/gnome-shell
...
Comment 2 Pierre Ossman 2013-05-06 06:17:27 EDT
Looking at the code in the backtrace, it seems to have something to do with logind. loginctl shows a session for the relevant instance of gnome-shell though.
Comment 3 Pierre Ossman 2013-05-06 07:09:43 EDT
I may have found the issue. XDG_SESSION_ID isn't properly propagated down to gnome-shell. I'll have a look at fixing that.

Still, gnome-shell should be able to start up without that set IMO.
Comment 4 Pierre Ossman 2013-05-06 08:34:48 EDT
(In reply to comment #3)
> I may have found the issue. XDG_SESSION_ID isn't properly propagated down to
> gnome-shell. I'll have a look at fixing that.
> 
> Still, gnome-shell should be able to start up without that set IMO.

Yup. With XDG_SESSION_ID properly set, gnome-shell starts up. So what's left in this bug is to make gnome-shell more tolerant of non-systemd environments.
Comment 5 procaccia 2013-07-05 04:51:03 EDT
I have the same pb . When fedora19 (64 bits) boots, I get an Xorg session start, then the fedora logo in the center of the screen with no login screen or whatever gdm, gnome-shell coming after . I checked /var/log/messages, it contains

Jul  5 09:35:53 b01-02 /usr/bin/dbus-launch[964]: JS ERROR: !!!   Exception in callback for signal: sessions-loaded
Jul  5 09:35:53 b01-02 /usr/bin/dbus-launch[964]: JS ERROR: !!!     message = '"malformed UTF-8 character sequence at offset 4"'
Jul  5 09:35:53 b01-02 /usr/bin/dbus-launch[964]: JS ERROR: !!!     fileName = '"/usr/share/gnome-shell/js/ui/status/keyboard.js"'
Jul  5 09:35:53 b01-02 /usr/bin/dbus-launch[964]: JS ERROR: !!!     lineNumber = '535'
Jul  5 09:35:53 b01-02 /usr/bin/dbus-launch[964]: JS ERROR: !!!     stack = '"()@/usr/share/gnome-shell/js/ui/status/keyboard.js:535
Jul  5 09:35:53 b01-02 /usr/bin/dbus-launch[964]: wrapper()@/usr/share/gjs-1.0/lang.js:213
Jul  5 09:35:53 b01-02 /usr/bin/dbus-launch[964]: ([object Object])@/usr/share/gnome-shell/js/ui/status/keyboard.js:384
...

I didn't understand the XDG_SESSION_ID issue mentioned above !? is this a bug, how can we correct it ? with that , the system is graphically completely unusable .
thanks .
Comment 6 Sergei I. Korolev 2013-08-06 20:59:36 EDT
I found what in js/misc/loginManager.js function haveSystemd() used quick and dirty way for detect systemd present like "GLib.access("/run/systemd/seats", 0) >= 0". In many systems systemd has been installed by depends but realy not used. And in this case this function work incorrect and try to use not running systemd. For fix this bug need rewrite function for detect realy running system with systemd or not.
Comment 7 Florian Müllner 2013-08-07 06:19:00 EDT
(In reply to Sergei I. Korolev from comment #6)
> "GLib.access("/run/systemd/seats", 0) >= 0". In many systems systemd has
> been installed by depends but realy not used.

This file is supposed to be created by systemd on startup, e.g. it exists if (and only if) systemd is running.
Comment 8 Sergei I. Korolev 2013-08-07 06:31:34 EDT
(In reply to Florian Müllner from comment #7)
> (In reply to Sergei I. Korolev from comment #6)
> > "GLib.access("/run/systemd/seats", 0) >= 0". In many systems systemd has
> > been installed by depends but realy not used.
> 
> This file is supposed to be created by systemd on startup, e.g. it exists if
> (and only if) systemd is running.

root@silvertablet:~# systemctl status
Failed to get D-Bus connection: No connection to service manager.

root@silvertablet:~# ls -l /var/run/systemd/
итого 0
drwxr-xr-x 2 root root 80 авг  7 04:34 inhibit
drwxr-xr-x 2 root root 60 авг  7 04:33 seats
drwxr-xr-x 2 root root 40 авг  7 04:33 sessions
drwxr-xr-x 2 root root 40 авг  7 04:33 users

no systemd running
Comment 9 Pierre Ossman 2013-08-07 07:49:39 EDT
Also, systemd running is still an insufficient test. Gnome cannot assume it was started via systemd even if it's on a systemd machine.

So feel free to look for XDG_SESSION_ID, but act graceful when it is not set.
Comment 10 Arun S A G 2013-09-12 00:43:57 EDT
Is there a workaround?
Comment 11 Bob Gustafson 2013-12-15 13:28:29 EST
(In reply to Florian Müllner from comment #7)
> (In reply to Sergei I. Korolev from comment #6)
> > "GLib.access("/run/systemd/seats", 0) >= 0". In many systems systemd has
> > been installed by depends but realy not used.
> 
> This file is supposed to be created by systemd on startup, e.g. it exists if
> (and only if) systemd is running.

It seems as though the /run/systemd/seats is a directory, not a file

Mine currently contains a file 'seat0' which has contents:

[user1@hoho6 ~]$ cat /run/systemd/seats
cat: /run/systemd/seats: Is a directory
[user1@hoho6 ~]$ cd /run/systemd/seats
[user1@hoho6 seats]$ ls
seat0
[user1@hoho6 seats]$ ls -l
total 4
-rw-r--r--. 1 root root 152 Dec 15 09:44 seat0
[user1@hoho6 seats]$ cat seat0
# This is private data. Do not parse.
IS_VTCONSOLE=1
CAN_MULTI_SESSION=1
CAN_TTY=1
CAN_GRAPHICAL=1
ACTIVE=2
ACTIVE_UID=1000
SESSIONS=2 1
UIDS=1000 1000
[user1@hoho6 seats]$
Comment 12 Bob Gustafson 2013-12-15 13:42:05 EST
Interesting. When I reboot, then log in using vncviewer and then look at the same directory/file, I get different results.

Note that the SESSIONS is different, and the UIDS is different.

I would have expected a new seat file, perhaps seat1 which would contain the different data. The VNC login seems to overwrite the original seat0 data.

Now I will do a Log Out of the vncsession (which kills the running vnc components and see if the seat0 remains the same or goes back.

[user1@hoho6 ~]$ cd /run/systemd/seats
[user1@hoho6 seats]$ ls -l
total 4
-rw-r--r--. 1 root root 151 Dec 15 12:33 seat0
[user1@hoho6 seats]$ cat seat0
# This is private data. Do not parse.
IS_VTCONSOLE=1
CAN_MULTI_SESSION=1
CAN_TTY=1
CAN_GRAPHICAL=1
ACTIVE=1
ACTIVE_UID=1000
SESSIONS=1 c4
UIDS=1000 42
[user1@hoho6 seats]$
Comment 13 Bob Gustafson 2013-12-15 13:52:10 EST
Interesting. The username for 42 is nologin

[user1@hoho6 seats]$ grep 42 /etc/passwd
gdm:x:42:42::/var/lib/gdm:/sbin/nologin
[user1@hoho6 seats]$
Comment 14 Bob Gustafson 2013-12-15 14:01:27 EST
Another experiment - I logged into an adjacent system on my LAN using ssh and looked at the /run/systemd/seats/seat0 file.

[user1@hoho6 seats]$ ssh hoho0
user1@hoho0's password: 
Last login: Sun Dec 15 07:32:51 2013 from hoho6.chidig.com
[user1@hoho0 ~]$ 
[user1@hoho0 ~]$ ls -l /run/systemd/seats
total 4
-rw-r--r--. 1 root root 143 Dec 15 08:09 seat0
[user1@hoho0 ~]$ cat /run/systemd/seats/seat0
# This is private data. Do not parse.
IS_VTCONSOLE=1
CAN_MULTI_SESSION=1
CAN_TTY=1
CAN_GRAPHICAL=1
ACTIVE=c3
ACTIVE_UID=42
SESSIONS=c3
UIDS=42

The hoho0 system had been updated and rebooted about half an hour ago. The console had not been used at all - no logins since reboot. The ssh session was the first login.
Comment 15 Bob Gustafson 2013-12-15 14:05:39 EST
Another experiment - logging into hoho0 as an additional separate user

[bobg@hoho0 ~]$ ls /run/systemd/seats
seat0
[bobg@hoho0 ~]$ ls -l /run/systemd/seats
total 4
-rw-r--r--. 1 root root 143 Dec 15 08:09 seat0
[bobg@hoho0 ~]$ cat /run/systemd/seats/seat0
# This is private data. Do not parse.
IS_VTCONSOLE=1
CAN_MULTI_SESSION=1
CAN_TTY=1
CAN_GRAPHICAL=1
ACTIVE=c3
ACTIVE_UID=42
SESSIONS=c3
UIDS=42
[bobg@hoho0 ~]$

Does not seem to change the data. The data is probably for graphical users only.
Comment 16 Pierre Ossman 2013-12-16 01:41:56 EST
(In reply to Bob Gustafson from comment #11)
> 
> It seems as though the /run/systemd/seats is a directory, not a file
> 

Seats represent physical access to the machine, not remote desktops such as VNC or SSH.

And please try to conduct these discussions on a mailing list or similar rather than in bugzilla. You are just filling up these entries with a lot of noise at this point.
Comment 17 Fedora End Of Life 2015-01-09 13:03:13 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 18 Fedora End Of Life 2015-02-17 10:10:00 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.