Created attachment 812105 [details] Failed boot Description of problem: I'm getting an increasing rate of boots that do not eventually provide a login screen. Today, I had to boot the laptop 4 times to eventually get a login screen. The first and third boots look normal up to the point of producing the Fedora balloon in the center of the screen, but then that image does NOT eventually convert over to a login screen. It just hangs there. I had to go to a terminal session and "shutdown -r now" to reboot the box to try again. Terminal login as root is fine. The disk looks fine. Everything I expect to see is there. The second boot gave me the square box that you're only supposed to see the first boot after an install where it ask to confirm the language, etc, and add a user if you didn't do that as part of the install process. I extracted the logs for each of the 4 boots and discovered that on some of them there is no "gnome-session" whatsoever in the log of that boot. For each log segment, I converted all digits to spaces so times and process ID's were eliminated. Then a diff -y between boots shows a fairly consistent boot process until the failed boot just ends and the successful one continues with this as the first line: dbus-daemon[ ]: dbus[ ]: [system] Activating via systemd: service name='org.freedesktop.UPower' unit='upower.service' followed a few lines later by : gnome-session[ ]: Entering running state and then lots of gnome-session message. How reproducible: Difficult, but getting easier as this is accelerating. It randomly does not bring up a login screen. Additional info: I'm having a battery issue on this box. The battery is only 5 months old but it is already just getting to 95% and the hardware led is telling me the battery has a problem. I'm attaching a failed log (third.noDigits) and a successful log (fourth.NoDigits) and I used diff -y third.noDigits fourth.noDigits to see the difference.
How do I attach another file (fourth.noDigits) as promises above?
I've now had the same issue on a completely different machine - a brand new standard desktop box. On this new machine, I see an actual failure of gdm: GdmLocalDisplayFactory: Failed to issue method call: Timeout was reached. On my laptop, I see no such failure message, nor do I see any reference to a gdm process.
systemctl status gdm shows everything is normal, but there is no login screen. Going to a terminal screen and : systemctl restart gdm causes a login screen to show up. It switches to the login screen automatically.
Also, this problem occurs sporadically. Sometimes the gdm login screen appears after a second reboot.
Also, this problem is occurring with F19, but with i686, 32-bit. Kernel version 3.12.x.
Also on gdm-3.10.0.1-1.fc20.x86_64 on Fedora 20
Created attachment 882839 [details] output from journalctrl -b -a -l Attached is the output from journalctl after reproducing the issue with Enable=True in the debug section of /etc/gdm/custom.conf and selinux in permissive mode
Faced the same problem on Fedora 20 i686 up to date. In another Red HAt Bugzilla report, they suggested 'sudo mv /var/log/journal /var/log/journal.org' which I successfully tried. Thus this brings me a question to Fedora maintainers : instead of /var/log/journal, why is this directory not created in /var/tmp/journal ? Yours truly, Philippe
attaching journalctl and logs from Xorg after adding Environment="SYSTEMD_LOG_LEVEL=debug" "SYSTEMD_LOG_TARGET=kmsg" to /etc/systemd/system/systemd-logind.service
Created attachment 899083 [details] journalctl
Created attachment 899084 [details] Xorg.log
So the GDM error mentioned in comment 2 is because logind isn't working. according to the logs in comment 10, logind isn't work because: maj 25 20:34:19 localhost.localdomain systemd-logind[1099]: Failed to enable subscription: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. maj 25 20:34:19 localhost.localdomain systemd[1]: bus_get_selinux_security_context failed: Resource temporarily unavailable maj 25 20:34:19 localhost.localdomain systemd[1]: Failed to get caller's security context on: Resource temporarily unavailable (ignore the "Resource temporarily unavailable", that's from an errant "%m" in the log output) system is failing when talking to the dbus daemon, but I don't think it prints the dbus error message, so hard to say more. Might be some sort of selinux issue, or issue fetching peer credentials, or so.
I started this thread and so I've probably been living with this issue the longest. I suspect its a timing problem. If it were Selinux, my guess is that it would fail the same way every time, causing a complete lockout every time - a bricked machine. I reported problems in Fedora twice before that turned out to be a timing issues (unrelated to this issue), and this also feels like one. I think a process is assuming a resource is available when its not and isn't handling the error via a retry. Booting a box 3 or 4 times to get a successful login screen when nothing changes from one to the next - what else could it be but some random timing issue?
Well, no disagreement that it could be a timing issue, but it could also just be a sporadic crash in the dbus-daemoncould be, say, a sporadic crash in the dbus daemon. One idea could be that /var/run is getting wiped (or relabeled?) at boot up clearing the dbus socket file after the system bus is started. Say by systemd-tmpfiles or something.
dbus seem fine: [root@localhost ~]# systemctl status dbus.service -l dbus.service - D-Bus System Message Bus Loaded: loaded (/usr/lib/systemd/system/dbus.service; static) Active: active (running) since fre 2014-05-30 10:06:32 CEST; 2h 35min ago Main PID: 1102 (dbus-daemon) CGroup: /system.slice/dbus.service └─1102 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation maj 30 12:37:29 localhost.localdomain dbus[1102]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' maj 30 12:37:29 localhost.localdomain dbus[1102]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. maj 30 12:39:29 localhost.localdomain dbus-daemon[1102]: dbus[1102]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' maj 30 12:39:29 localhost.localdomain dbus[1102]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' maj 30 12:39:29 localhost.localdomain dbus[1102]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. maj 30 12:39:29 localhost.localdomain dbus-daemon[1102]: dbus[1102]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. maj 30 12:41:29 localhost.localdomain dbus-daemon[1102]: dbus[1102]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' maj 30 12:41:29 localhost.localdomain dbus-daemon[1102]: dbus[1102]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. maj 30 12:41:29 localhost.localdomain dbus[1102]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' maj 30 12:41:29 localhost.localdomain dbus[1102]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. Not sure about those complaints regarding ModemManager... Also the systembus-socket seem to be there: [root@localhost ~]# ls -lZ /var/run/dbus/system_bus_socket srw-rw-rw-. root root system_u:object_r:system_dbusd_var_run_t:s0 /var/run/dbus/system_bus_socket Also attaching with "dbus-monitor --system" and i can see messages coming through so dbus really dus seem to be OK.
I did a yum update last night and shut down the laptop. I noticed no kernel updates. This morning it took 7 CTRL-ALT-DEL sessions to finally get a login screen. My new record! Most of those boots presented the usual symptom - a successful load of a sendmail component as the last prompt on the boot log screen. Two boots however were different. Started NTP client/server. Started NTP client/server.ript Dispatcher Service ....RT) Daemon.... 415-######## ...Locks... The last message appears to be a mashup of two messages. Two boots presented essentially the same output. Those boots also reacted differently to ESC. Once at the boot log screen it wouldn't revert back to the Fedora balloon screen. CTRL-ALT-DEL didn't function in a timely manner - there was a huge delay. When one of my employees saw me trying to boot up my box, she said that she had experienced the same failure (hung after successful sendmail process) on an F18 laptop we use for a dedicated function. She claimed it only happened to her twice in over a year, if that's any help.
Bill, this is of course not a solution but as a workaround, I've discovered that if you disable graphical boot ( remove "rhgb quiet" from /etc/default/grub and run "grub2-mkconfig -o /boot/grub2/grub.cfg") the problem occurs less frequently.
David - Thanks for the reminder. I usually do that to my servers, but just never thought about it for my personal box. When I booted my box this morning it came up the first time. If there were some convenient way of lying to NTP so as to tell it it's yesterday, I'd like to try that. 7 boots yesterday and 1 today and NTP was the last reliable message I saw yesterday. Coincidence?
Created attachment 901792 [details] snapshot of messages on failed boot Now that I turned off rhgb, there are more messages visible.
FWIW I'm also seeing this on Fedora 20 i686 but it only seemed to happen after I installed the sugar desktop environment (which also installs lightdm). But after trying the rhgb hack mentionned above the gdm chooser does finally come up. The error in gdm.service status is the same as that mentionned in comment 2. # systemctl status gdm gdm.service - GNOME Display Manager Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled) Active: active (running) since Wed 2014-08-13 21:04:18 EDT; 4min 21s ago Main PID: 426 (gdm) CGroup: /system.slice/gdm.service ├─426 /usr/sbin/gdm ├─512 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Displays/_0 └─616 /usr/bin/Xorg :0 -background none -verbose -auth /run/gdm/auth-for-gdm-04pzXz/database -seat seat0 -nolisten tcp Aug 13 21:04:53 bobenzo gdm[426]: GdmLocalDisplayFactory: Failed to issue method call: Timeout was reached
I'm still seeing it on F19 regularly. I have to multi boot my box at least 3 times a week. I don't think the rhgb change makes a difference. One thing I did notice is I can tell by the messages on the screen that a particular boot will hang. I get a double set of Sendmail messages as the last thing on the screen.
it happens also on my laptop, I can wait half-an.hour or longer but nothing happens. I filed a bug https://bugzilla.redhat.com/show_bug.cgi?id=1139346 as I didn't note this bug. Someone on the mailing of fedora users pointed this bug. Funny as the number of reboots seems to be increasing since two days.Last time last messages were about Network Despatch Manager....
And I am suffering of same symptoms of comment #12
did the reporter try to work with selinux=permissive??
switching to init 3 and issuing a startx, it works....selinux is not affecting this bug
forgot to say that is a 64 bit Fedora 20
@antonio montagnani - Selinux as the source of the issue makes no sense to me, so - NO - I didn't try it. Even if it worked, I wouldn't use that as a work around as it's too dangerous. I still think it's a sequence of events issue. Ethernet Connectivity is my guess, as sendmail keeps bombing out and my machine is wirelessly connected to a gateway box which is connected via a firewall to an Internet connection.
I switched to kdm and so far I have no problem: please wait for confirmation
Confirmed: kdm works fine, no issue so far
there is one drawback in using kdm instead of gdm, that screen power management doesn't work
In reply to #27: I have verified that the problem can be seen with selinux in permissive mode (comment #7) I also encounter the problem with a (wired) ethernet connection, so it's not about wireless. I haven't however investigated if this could somehow be related to my uplink.
it seems a silly comment: I changed the time of screen blanking from 1 minute to 5 minutes and issue seems gone. Crazy, isn't it??
My machine was set to five minute screen-blank time all along and still the problem manifested
can you increase it more ot set not to have screen-blank??
Also have this problem (Fedora 21 -8gig ram, dual core cpu) Resolution for now... log to root via virtual terminal issue startx On some boot sequences, I do see the start Gnome-session. but the system does not proceed further. On other occasions, I see the last viewed log message as waiting for the printer.... There is a USB plugged printer on this system, as well as a usb webcam. In my case, I think that if I wait long enough, (5-10 minutes), the system will come up on its own fully.
I started this thread and had no screen blanking originally when I first encountered the problem. Later, I initiated screen blanking at the 15 min mark. As far as I'm concerned, screen blanking has nothing to do with it.
In response to #35: This sounds like a different issue, if I would dare a guess, something is waiting on some USB probing that shouldn't be waiting. Please file a new bug about this issue.
issue reappered again: gdm-3.10.0.1-1.fc20.x86_64 that is about one year old while bug is marked as high (In the meantime I see gdm-3.14.0-1.fc22 in the wild!!! and we do not know whether such issue has been solved)
It's apparent that this incident is not being worked on, so I thought that we, the people experiencing the problem, should try to work on it by collaborating here via this thread. To that end, I was going to concentrate on what I believe could be the source of the problem, which is a timing issue (sequence of events) concerning when my Ethernet becomes active relative to some service that needs the Ethernet and discovers it's not available yet and hangs up the box. I can always tell when a boot is NOT going to produce the login screen. I see a particular series of Sendmail messages that make no sense. So, I decided to look into /var/log/messages to start the investigation. What I discovered however was a surprise, at least to me. The Sendmail messages I see on screen during the failed boot attempts are not accurately reflected in /var/log/messages, and what's in /var/log/messages doesn't even make sense. Here's a sample for the 5 boot attempts it took this morning to finally get a login screen, each bracketed by its rsyslogd entries: grep 'Oct 5' /var/log/messages|grep -e rsyslogd -e Sendmail -e sendmail|cat -n 1 Oct 5 07:16:21 billlaptop rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="579" x-info="http://www.rsyslog.com"] start 2 Oct 5 07:17:10 billlaptop systemd[1]: Starting Sendmail Mail Transport Agent... 3 Oct 5 07:17:11 billlaptop systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start. 4 Oct 5 07:17:12 billlaptop systemd[1]: Stopping Sendmail Mail Transport Client... 5 Oct 5 07:17:12 billlaptop systemd[1]: Stopping Sendmail Mail Transport Agent... 6 Oct 5 07:17:12 billlaptop systemd[1]: Starting Sendmail Mail Transport Agent... 7 Oct 5 07:17:12 billlaptop systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start. 8 Oct 5 07:17:12 billlaptop systemd[1]: Started Sendmail Mail Transport Agent. 9 Oct 5 07:17:12 billlaptop systemd[1]: Starting Sendmail Mail Transport Client... 10 Oct 5 07:17:12 billlaptop systemd[1]: Started Sendmail Mail Transport Client. 11 Oct 5 07:17:14 billlaptop systemd[1]: Stopping Sendmail Mail Transport Client... 12 Oct 5 07:17:14 billlaptop systemd[1]: Stopping Sendmail Mail Transport Agent... 13 Oct 5 07:17:14 billlaptop systemd[1]: Starting Sendmail Mail Transport Agent... 14 Oct 5 07:17:14 billlaptop systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start. 15 Oct 5 07:17:14 billlaptop systemd[1]: Started Sendmail Mail Transport Agent. 16 Oct 5 07:17:14 billlaptop systemd[1]: Starting Sendmail Mail Transport Client... 17 Oct 5 07:17:14 billlaptop systemd[1]: Started Sendmail Mail Transport Client. 18 Oct 5 07:18:57 billlaptop rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="579" x-info="http://www.rsyslog.com"] exiting on signal 15. 19 Oct 5 07:19:30 billlaptop rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="581" x-info="http://www.rsyslog.com"] start 20 Oct 5 07:20:15 billlaptop systemd[1]: Stopping Sendmail Mail Transport Client... 21 Oct 5 07:20:15 billlaptop systemd[1]: Stopping Sendmail Mail Transport Agent... 22 Oct 5 07:20:15 billlaptop systemd[1]: Starting Sendmail Mail Transport Agent... 23 Oct 5 07:20:15 billlaptop systemd[1]: Started Sendmail Mail Transport Agent. 24 Oct 5 07:20:15 billlaptop systemd[1]: Starting Sendmail Mail Transport Client... 25 Oct 5 07:20:15 billlaptop systemd[1]: Started Sendmail Mail Transport Client. 26 Oct 5 07:20:18 billlaptop systemd[1]: Stopping Sendmail Mail Transport Client... 27 Oct 5 07:20:18 billlaptop systemd[1]: Stopping Sendmail Mail Transport Agent... 28 Oct 5 07:20:18 billlaptop systemd[1]: Starting Sendmail Mail Transport Agent... 29 Oct 5 07:20:18 billlaptop systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start. 30 Oct 5 07:20:18 billlaptop systemd[1]: Started Sendmail Mail Transport Agent. 31 Oct 5 07:20:18 billlaptop systemd[1]: Starting Sendmail Mail Transport Client... 32 Oct 5 07:20:18 billlaptop systemd[1]: Started Sendmail Mail Transport Client. 33 Oct 5 07:22:44 billlaptop rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="581" x-info="http://www.rsyslog.com"] exiting on signal 15. 34 Oct 5 07:23:16 billlaptop rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="581" x-info="http://www.rsyslog.com"] start 35 Oct 5 07:24:02 billlaptop systemd[1]: Stopping Sendmail Mail Transport Client... 36 Oct 5 07:24:02 billlaptop systemd[1]: Stopping Sendmail Mail Transport Agent... 37 Oct 5 07:24:02 billlaptop systemd[1]: Starting Sendmail Mail Transport Agent... 38 Oct 5 07:24:02 billlaptop systemd[1]: Started Sendmail Mail Transport Agent. 39 Oct 5 07:24:02 billlaptop systemd[1]: Starting Sendmail Mail Transport Client... 40 Oct 5 07:24:03 billlaptop systemd[1]: Started Sendmail Mail Transport Client. 41 Oct 5 07:24:05 billlaptop systemd[1]: Stopping Sendmail Mail Transport Client... 42 Oct 5 07:24:05 billlaptop systemd[1]: Stopping Sendmail Mail Transport Agent... 43 Oct 5 07:24:05 billlaptop systemd[1]: Starting Sendmail Mail Transport Agent... 44 Oct 5 07:24:05 billlaptop systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start. 45 Oct 5 07:24:05 billlaptop systemd[1]: Started Sendmail Mail Transport Agent. 46 Oct 5 07:24:05 billlaptop systemd[1]: Starting Sendmail Mail Transport Client... 47 Oct 5 07:24:05 billlaptop systemd[1]: Started Sendmail Mail Transport Client. 48 Oct 5 07:25:49 billlaptop rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="581" x-info="http://www.rsyslog.com"] exiting on signal 15. 49 Oct 5 07:26:22 billlaptop rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="584" x-info="http://www.rsyslog.com"] start 50 Oct 5 07:27:04 billlaptop systemd[1]: Started Sendmail Mail Transport Client. 51 Oct 5 07:27:05 billlaptop systemd[1]: Stopping Sendmail Mail Transport Client... 52 Oct 5 07:27:05 billlaptop systemd[1]: Stopping Sendmail Mail Transport Agent... 53 Oct 5 07:27:05 billlaptop systemd[1]: Starting Sendmail Mail Transport Agent... 54 Oct 5 07:27:05 billlaptop systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start. 55 Oct 5 07:27:05 billlaptop systemd[1]: Started Sendmail Mail Transport Agent. 56 Oct 5 07:27:05 billlaptop systemd[1]: Starting Sendmail Mail Transport Client... 57 Oct 5 07:27:05 billlaptop systemd[1]: Started Sendmail Mail Transport Client. 58 Oct 5 07:27:10 billlaptop systemd[1]: Stopping Sendmail Mail Transport Client... 59 Oct 5 07:27:10 billlaptop systemd[1]: Stopping Sendmail Mail Transport Agent... 60 Oct 5 07:27:10 billlaptop systemd[1]: Starting Sendmail Mail Transport Agent... 61 Oct 5 07:27:11 billlaptop systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start. 62 Oct 5 07:27:11 billlaptop systemd[1]: Started Sendmail Mail Transport Agent. 63 Oct 5 07:27:11 billlaptop systemd[1]: Starting Sendmail Mail Transport Client... 64 Oct 5 07:27:11 billlaptop systemd[1]: Started Sendmail Mail Transport Client. 65 Oct 5 07:27:15 billlaptop rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="584" x-info="http://www.rsyslog.com"] exiting on signal 15. 66 Oct 5 07:27:52 billlaptop rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="580" x-info="http://www.rsyslog.com"] start 67 Oct 5 07:28:47 billlaptop systemd[1]: Stopping Sendmail Mail Transport Client... 68 Oct 5 07:28:47 billlaptop systemd[1]: Stopping Sendmail Mail Transport Agent... 69 Oct 5 07:28:47 billlaptop systemd[1]: Starting Sendmail Mail Transport Agent... 70 Oct 5 07:28:47 billlaptop systemd[1]: Started Sendmail Mail Transport Agent. 71 Oct 5 07:28:47 billlaptop systemd[1]: Starting Sendmail Mail Transport Client... 72 Oct 5 07:28:47 billlaptop systemd[1]: Started Sendmail Mail Transport Client. 73 Oct 5 07:28:50 billlaptop systemd[1]: Stopping Sendmail Mail Transport Client... 74 Oct 5 07:28:50 billlaptop systemd[1]: Stopping Sendmail Mail Transport Agent... 75 Oct 5 07:28:50 billlaptop systemd[1]: Starting Sendmail Mail Transport Agent... 76 Oct 5 07:28:50 billlaptop systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start. 77 Oct 5 07:28:50 billlaptop systemd[1]: Started Sendmail Mail Transport Agent. 78 Oct 5 07:28:50 billlaptop systemd[1]: Starting Sendmail Mail Transport Client... 79 Oct 5 07:28:50 billlaptop systemd[1]: Started Sendmail Mail Transport Client. Notice line #4. It is stopping the Client, but the Starting and Started messages for the Client are in lines #9 & #10. As a sequence of events, this log is useless. I always thought that the log represented an accurate sequence of events. Apparently, it does not. Of the 5 boot sessions, The following count of Sendmail Agent & Client messages are observed. Boot Agent Client 1 7 6 2 6 6 3 6 6 4 6 7 5 6 6 Why is Sendmail starting and stopping its components? Could it be that it is lacking a resource it depends on, namely the Ethernet? During the boot, in the on screen messages I see Ethernet messages intermingled within the Sendmail messages and those intermingled Ethernet messages don't even show up in var/log/messages. Is anyone else seeing Sendmail events as I've described?
I suspect that you're right that this problem is timing related, but whether it is network or dbus or some combination of subsystems that is the root cause I can't say. It's possible that this bizarre logging of sendmail is related to the way it deals with startup without network. Have you considered switching to postfix to see if it is just some weird sendmail behaviour (I do recall excruciating boot waits for sendmail timeouts back in the olden days, maybe this is just how the issue is being dealt with in this modern era :) Anyway, I would suggest giving postfix a try, it's far easier to manage than sendmail, and might help to eliminate sendmail as anything but a side-effect of the gdm timeout related to this issue.
are all the reporters using laptops, i.e. no Ethernet connected at start-up?? On my laptop situation is getting worse, now half of times I have to reboot and this morning login screen came up at third trial. Marked as high but no sign of life from assignee...
and I have neither sendmail nor postfix installed....
I saw this issue on a stationary Fedora 19 machine. I'm not sure if we're talking about the same problem any more, but for me, the problem went away if I disabled rhgb as described in comment #17
I confirm that removing rhgb quiet bug seems gone away. Surprised that bug is marked high but no work on it. Am I alone ? :-)
don't know if it can be useful in debugging, this is the output of a successful boot systemd-analyze blame 30.169s plymouth-quit-wait.service 26.377s NetworkManager.service 26.377s accounts-daemon.service 25.820s ModemManager.service 25.665s chronyd.service 13.284s rsyslog.service 3.937s systemd-tmpfiles-setup.service 3.125s lvm2-monitor.service 2.492s lvm2-pvscan@8:3.service 2.310s proc-fs-nfsd.mount 1.514s var-lib-nfs-rpc_pipefs.mount 1.419s systemd-fsck-root.service 1.399s systemd-fsck@dev-disk-by\x2duuid-ee7fed51\x2d1613\x2d4cd8\x2da5 1.367s dev-mqueue.mount 1.367s dev-hugepages.mount 1.363s boot.mount 1.162s systemd-udev-trigger.service 1.149s systemd-tmpfiles-clean.service 1.123s nfs-lock.service 1.096s sys-kernel-debug.mount 1.062s firewalld.service 912ms systemd-tmpfiles-setup-dev.service 902ms systemd-fsck@dev-mapper-fedora\x2dhome.service
So this definitely isn't a GDM issue (See comment 12 and comment 14). I don't know if it's systemd issue or dbus issue or what. Lacking more insight, and the ability to reproduce, I'm going to reassign to systemd for now. At a minimum, it could log the error message and give better insight into what's going on, and then maybe we can catch traction on the issue. Sorry guys, I probably should have moved this over a long time ago.
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.