Bug 715467

Echoing fcrozat from IRC, since he has no bugzilla access atm: 

check if pam_systemd is in /etc/pam.d/common-session

(In reply to comment #1)
> Echoing fcrozat from IRC, since he has no bugzilla access atm: 
> 
> check if pam_systemd is in /etc/pam.d/common-session

session optional        pam_systemd.so

if it is caused by systemd, try booting with systemd.log_level=debug systemd.log_target=kmsg

Created attachment 449715 [details]
dmesg with debuginfo

I haven't tried booting with sysvinit yet. This bug is not 100% reproducible. Should I try that?

(In reply to comment #4)
> Created an attachment (id=449715) [details]
> dmesg with debuginfo
> 
> I haven't tried booting with sysvinit yet.

Yes, I tried several times with sysvinit and it works fine.

Hmm, there is a cycle in your dependencies but I don't think it is causing the issue.. Could you test systemd package from home:fcrozat:systemd ? it should fixes some dependency cycle.

(In reply to comment #6)
> Hmm, there is a cycle in your dependencies but I don't think it is causing the
> issue.. Could you test systemd package from home:fcrozat:systemd ? it should
> fixes some dependency cycle.

After the update I haven't seen the issue again so far...

good, closing as fixed, reopen if needed

Hmm, it reappeared. And it happened 3 times in a row now.

I upgraded a kernel to a bleeding edge (3.1-rc9-next) and there is a networking issue. It lasts long before network device becomes available (waiting for mandatory devices times out). After some time the network works. Maybe unavailable network triggers the issue?

And since it is reproducible I catched a debug systemd output. I will attach it now.

Created attachment 455352 [details]
dmesg output with systemd debug turned on

Ah, and this:
# rpm -q `rpmqpack |grep systemd`
systemd-36-1.1.x86_64
systemd-presets-branding-openSUSE-0.1.0-3.1.noarch

It looks like an old CK bug, which has been fixed years ago : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562026

FWIW, the CK bug was fixed in 0.4.2 and we have 0.4.5 now :-)

Based on the commit message from the fix (http://cgit.freedesktop.org/ConsoleKit/commit/?id=2418840248f07025ad0edc96ed17e03ce5e47f3e) it looks like an issue caused by systemd feature to take dbus names instead of starting the service: this creates the same race that got fixed by the CK commit a few years ago.

so, kdm shouldn't rely on the dbus names just being available on the bus, I guess ?

Well, I don't know if this is what kdm does. What's weird is that with the fix from upstream, this specific race should be gone. So there's likely a similar issue still around, but it needs debugging by people who can reproduce.

For instance, knowing what happens inside kdm and ConsoleKit when this happens would be useful.

*** Bug 722908 has been marked as a duplicate of this bug. ***

Is this bug still there on 12.1 ?

yes

cannot say I see it every time

it is enough to "init 3", "init 5"

if I start console-kit-daemon from tty1 after "init 5" and before logging in, there is no error

found no link to console-kit.daemon.service in 
/etc/systemd/system/graphical.target.wants

will init 3 -> init 5 when I have local access to
subject machine later today and report.

If doesn't exist with init changes will do a shutdown/start
seq and report...

made link indicated above and now console-kit-daemon functions as expected.

Solution is to enable the service, console-kit-daemon when a graphical target is defined.


tks,

Possibly related: bug #732642, bug #739772, bug #728731, bug #736695

This happens every boot.  Non-starters are alsasound, apcupsd, dbus, postfix, random & smartd.   When I can (through some trickery which I cannot remember) enable sound applications to play(not just the test sound, which always works) it will cease to work after a few hours and I find that alsasound, avahi-daemmon, kbd and random must be restarted.

Created attachment 485210 [details]
KDE crash file

This bug is not KDE-specific.  It happens when I log in to a console session as well,

Feb  8 18:04:15 ne-1-26 systemd-logind[645]: New session 1 of user root.
Feb  8 18:04:15 ne-1-26 dbus-daemon[699]: dbus[699]: [system] Activating systemd to hand-off: service name='org.freedesktop.ConsoleKit' unit='console-kit-daemon.service'
Feb  8 18:04:15 ne-1-26 dbus[699]: [system] Activating systemd to hand-off: service name='org.freedesktop.ConsoleKit' unit='console-kit-daemon.service'
Feb  8 18:04:40 ne-1-26 dbus-daemon[699]: dbus[699]: [system] Failed to activate service 'org.freedesktop.ConsoleKit': timed out
Feb  8 18:04:40 ne-1-26 dbus-daemon[699]: dbus[699]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
Feb  8 18:04:40 ne-1-26 dbus-daemon[699]: process 699: arguments to dbus_message_set_reply_serial() were incorrect, assertion "reply_serial != 0" failed in file dbus-message.c line 1070.
Feb  8 18:04:40 ne-1-26 dbus-daemon[699]: This is normally a bug in some application using the D-Bus library.
Feb  8 18:04:40 ne-1-26 dbus-daemon[699]: D-Bus not built with -rdynamic so unable to print a backtrace
Feb  8 18:04:40 ne-1-26 dbus[699]: [system] Failed to activate service 'org.freedesktop.ConsoleKit': timed out
Feb  8 18:04:40 ne-1-26 dbus[699]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
Feb  8 18:04:40 ne-1-26 login: ROOT LOGIN ON tty1
Feb  8 18:04:40 ne-1-26 avahi-daemon[642]: Disconnected from D-Bus, exiting.
Feb  8 18:04:40 ne-1-26 avahi-daemon[642]: Got SIGTERM, quitting.
Feb  8 18:04:40 ne-1-26 avahi-daemon[642]: Leaving mDNS multicast group on interface eth0.IPv4 with address 10.8.1.26.
Feb  8 18:04:40 ne-1-26 avahi-daemon[642]: Leaving mDNS multicast group on interface eth1.IPv4 with address 192.168.0.1.
Feb  8 18:04:40 ne-1-26 avahi-daemon[642]: avahi-daemon 0.6.31 exiting.
Feb  8 18:04:40 ne-1-26 systemd[1]: systemd-logind.service: main process exited, code=exited, status=1
Feb  8 18:04:40 ne-1-26 systemd[1]: Unit systemd-logind.service entered failed state.
Feb  8 18:04:40 ne-1-26 systemd[1]: dbus.service: main process exited, code=killed, status=6
Feb  8 18:04:40 ne-1-26 systemd[1]: Unit dbus.service entered failed state.
Feb  8 18:04:40 ne-1-26 systemd[1]: Startup finished in 6s 621ms 753us (kernel) + 1min 45s 797ms 494us (userspace) = 1min 52s 419ms 247us.

Several facts:

  1. 
console-kit-daemon.service is supposed to be activated by log in to console.  It should talk back to log in to set the environment variable $XDG_SESSION_COOKIE containing a ticket to removable media.  When it fails, causing a noticeable delay at log in, $XDG_SESSION_COOKIE is not set and access to removable media is denied.

  2. 
The failure occurs only the first time after boot.  Subsequent log in does not exhibit this problem.

  3.
console-kit-daemon.service is supposed to start console-kit-daemon which stores its process identifier in file /var/run/ConsoleKit/pid.  After it fails at log in, the directory /var/run/ConsoleKit does not exist; systemctl reports the service is not running.

  4.
It is possible to start console-kit-daemon.service after logging in as root.  The service starts with no problems when started manually.

  5.
I was unable to find any problem report from console-kit-daemon itself.  However, I am not sure it is supposed to report upon failure.

(In reply to comment #20)
> made link indicated above and now console-kit-daemon functions as expected.
> 
> Solution is to enable the service, console-kit-daemon when a graphical target
> is defined.
> 
> 
> tks,

Thanks for the hint! This is the appropriate command: "sudo systemctl enable console-kit-daemon.service".

endym

Let me, as a reporter, close this. I haven't seen this for ages, so this is fixed for me.

If you still have that problem, it can stem from a different source. Please open a *separate* bug for that and possibly link this one.