Edit /lib/systemd/system/console-kit-daemon.service to add "--debug" to the command line of console-kit-daemon. It will make c-k-d write its debug logs to  /var/log/messages after reboot.

K.

I will do that.

Attached file.  I see absolutely nothing that would help me debug the problem.

Created attachment 533647 [details]
var log messages

I see two weird things in the log:

Nov 14 22:39:24 karen rtkit-daemon[1787]: Warning: PolicyKit call failed: 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.
Nov 14 14:39:25 karen dbus[1772]: [system] Failed to activate service 'org.freedesktop.ConsoleKit': timed out

First, for some reason the line about rtkit-daemon seems to have a different idea about the timezone than the rest of the system.
Second, the failure to get a response from PolicyKit. If PolicyKit is not responding, then perhaps it influences ConsoleKit too.
PolicyKit is started by dbus as specified in /usr/share/dbus-1/system-services/org.freedesktop.PolicyKit1.service:
  Exec=/usr/libexec/polkit-1/polkitd --no-debug
Try deleting that "--no-debug".

And this is unfortunate:
Nov 14 14:39:25 karen rsyslogd-2177: imuxsock lost 100 messages from pid 1823 due to rate-limiting

Try to configure rsyslog's imuxsock to do less rate-limiting. I don't know rsyslog well enough to tell you how.

(In reply to comment #5)
> First, for some reason the line about rtkit-daemon seems to have a different
> idea about the timezone than the rest of the system.

This is likely due to rtkit-daemon running in a chroot. rsyslog has a fix for this in its devel branches. It is unrelated to the ConsoleKit problem.

(In reply to comment #5)
<snip>
> Try to configure rsyslog's imuxsock to do less rate-limiting. I don't know
> rsyslog well enough to tell you how.

There are two settings that you use in rsyslog for rate limit 

$SystemLogRateLimitInterval [number]
$SystemLogRateLimitBurst [number]

First setting determines the amount of time that is being measured for rate limiting

$SystemLogRateLimitInterval

And the second defines the amount of messages, that have to occur in the time limit of SystemLogRateLimitInterval, to trigger rate limiting.

$SystemLogRateLimitBurst 

By default this is set to 

$SystemLogRateLimitInterval 5
$SystemLogRateLimitBurst 200

Which means that rate limiting will take place if a process sends more than 200 messages in 5 seconds.

Note when changing these settings you should use the upstream syslog tester which can be found in the test folder to confirm if rsyslog picked up the new values ( + it's a good way to stress-testing for your rsyslog installation ) 

Simply cd into that directory then run make syslog_caller and then

./syslog_caller -m 3000

Which will send 3000 messages in one burst ( other switches can be found in the .c file of the tool. ).

OK, I have performed the two steps required of me here.  When I reboot the machine, I will collect the new info and re-upload.

Created attachment 534910 [details]
debug.log (all syslogoutput)

Still a mystery. Could you try if disabling rsyslog makes the bug go away?
systemctl disable rsyslog.service

Is this still an issue with on a fully updated release or can this
bug be closed?

This is a dupe of this:

https://bugzilla.redhat.com/show_bug.cgi?id=708866

*** This bug has been marked as a duplicate of bug 708866 ***