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
...

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.

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.

(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.

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 .

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.

(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.

(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

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.

Is there a workaround?

(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]$

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]$

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]$

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.

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.

(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.

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.

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.

Still valid bug for tigervnc server. Gnome fails to start when vncserver is started as systemd service, running vncserver by hand works just fine. Also running any other DE (e.g. KDE) over vncserver started as systemd service works fine as well.

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

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 25 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.

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.