Bug 228079

Created attachment 147816 [details]
lshal -l -u  /org/freedesktop/Hal/devices/volume_uuid_454C_0DAC_0

Are you logging in via gdm? Also, is the ConsoleKit service running?

I am not logging via gdm, but via wdm. 

How could I know whether ConsoleKit is running or not?

(In reply to comment #3)

> 
> How could I know whether ConsoleKit is running or not?

I found that 
console-kit-daemon is stopped.

Trying to launch it as root, I get:

#  /etc/init.d/ConsoleKit start
Starting console-kit daemon: 
** (console-kit-daemon:9970): WARNING **: Failed to acquire
org.freedesktop.ConsoleKit
FAILED

This may be unrelated, but I restarted dbus and now ConsoleKit
segfaults:

# /usr/sbin/console-kit-daemon  --debug  --no-daemon
[ck_debug_init] ck-debug.c:106 (00:14:59):       Debugging enabled
[main] main.c:121 (00:14:59):    initializing console-kit-daemon 0.1.0
[get_active_native] ck-vt-monitor.c:233 (00:14:59):      Current VT: tty7
[get_active_native] ck-vt-monitor.c:238 (00:14:59):      VT 1:on
[get_active_native] ck-vt-monitor.c:238 (00:14:59):      VT 2:on
[get_active_native] ck-vt-monitor.c:238 (00:14:59):      VT 3:on
[get_active_native] ck-vt-monitor.c:238 (00:14:59):      VT 4:on
[get_active_native] ck-vt-monitor.c:238 (00:15:00):      VT 5:on
[get_active_native] ck-vt-monitor.c:238 (00:15:00):      VT 6:on
[get_active_native] ck-vt-monitor.c:238 (00:15:00):      VT 7:on
[get_active_native] ck-vt-monitor.c:238 (00:15:00):      VT 8:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00):      VT 9:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00):      VT 10:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00):      VT 11:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00):      VT 12:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00):      VT 13:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00):      VT 14:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00):      VT 15:off
[get_active_native] ck-vt-monitor.c:238 (00:15:00):      VT 16:off
[watch_vts] ck-vt-monitor.c:271 (00:15:00):      Creating thread for vt 1
[watch_vts] ck-vt-monitor.c:271 (00:15:00):      Creating thread for vt 2
[watch_vts] ck-vt-monitor.c:271 (00:15:00):      Creating thread for vt 3
[watch_vts] ck-vt-monitor.c:271 (00:15:00):      Creating thread for vt 4
[watch_vts] ck-vt-monitor.c:271 (00:15:00):      Creating thread for vt 5
[watch_vts] ck-vt-monitor.c:271 (00:15:00):      Creating thread for vt 6
[watch_vts] ck-vt-monitor.c:271 (00:15:00):      Creating thread for vt 8
[watch_vts] ck-vt-monitor.c:271 (00:15:00):      Creating thread for vt 9
[watch_vts] ck-vt-monitor.c:271 (00:15:00):      Creating thread for vt 10
[watch_vts] ck-vt-monitor.c:271 (00:15:00):      Creating thread for vt 11
[watch_vts] ck-vt-monitor.c:271 (00:15:00):      Creating thread for vt 12
Erreur de segmentation


And the backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208337520 (LWP 10467)]
0x00ae0c90 in buffered_vfprintf (s=0xbee580, format=0x805245c "[%s] %s:%d
(%s):\t %s\n", args=0xb7fa2f2c "c\025\005\b�023\005\b�") at vfprintf.c:2122
2122    {
(gdb) bt
#0  0x00ae0c90 in buffered_vfprintf (s=0xbee580, format=0x805245c "[%s] %s:%d
(%s):\t %s\n", args=0xb7fa2f2c "c\025\005\b�023\005\b�") at vfprintf.c:2122
#1  0x00adcc5f in _IO_vfprintf_internal (s=0xbee580, format=0x805245c "[%s]
%s:%d (%s):\t %s\n", ap=0xb7fa2f2c "c\025\005\b�023\005\b�")
    at vfprintf.c:1270
#2  0x00b82c95 in ___fprintf_chk (fp=0xbee580, flag=1, format=0x805245c "[%s]
%s:%d (%s):\t %s\n") at fprintf_chk.c:37
#3  0x0804fa8e in ck_debug_real (func=0x8051563 "vt_thread_start",
file=0x80513cf "ck-vt-monitor.c", line=182, format=0x8051447 "VT_WAITACTIVE for
vt %d")
    at ck-debug.c:68
#4  0x0804c995 in vt_thread_start (data=0x9f0b180) at ck-vt-monitor.c:182
#5  0x0020229f in ?? () from /lib/libglib-2.0.so.0
#6  0x00d632db in start_thread (arg=0xb7fa3b90) at pthread_create.c:296
#7  0x00b6ed0e in clone () from /lib/libc.so.6

Seems like the segfault is in the debugging code. I could start
ConsoleKit. The error is still the same, but I guess I have to
relogin or something along such that ConsoleKit knows that I am here,
as it was dead when i loggued in first.

When loggued in gdm is works. Do you have an explanation?

Yes, see bug 228110 for details. Thanks.

The segfault is due to using the minimum stack size for the VT watching threads.
 Apparently glibc cannot do stdio with the minimum stack size.  This was fixed
in git:

http://gitweb.freedesktop.org/?p=ConsoleKit.git;a=commitdiff;h=dc427221e1c5028465f4a78132374662341ca3b7

What's the status on this?

I have contacted upstream some time ago, but the response is that
he doesn't have much time for wdm currently.

(CC'ing wwoods)

Patrice,

Do you think this bug qualifies us a release blocker? Any idea how widely wdm is
being used currently? If you don't have time to patch it I think we should take
this off the blocker and document this as a known issue. 

I don't think wdm is used a lot, but I don't know how to know
for sure, except that I haven't have any bug submitted so far.

I have no problem with that bug not being considered
as a release blocker.

However, since wdm is based on xdm, if there is a fix for xdm 
it may be possible for me to try to do the patching of wdm, and
the corresponding xdm bug could well be considered as a 
release blocker, I guess that there are indeed xdm users.

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

wdm could be fixed by passing the right pam environment
variables to pam_ck_connector, but lately I have seen the following in
the consolekit changelog:
        * Add new helper for getting tty from DISPLAY (William Jon McCann)
so I was hoping everything could be automatic, I asked for an
explanation on the hal list, and directly to David, so far no answer.
I also asked for clarification on the new pam variable that appeared
lately.

Somebody proposed me to use the kdm patch, but it is much too 
intrusive in my opinion to be used, since there exists less
intrusive solution (at least use libck-connector.so, even better
set the pam variables). 

In any case I think that the consolekit people should have 
tried much harder to use pam and conform to existing 
practices, but they don't seem to care (see Bug 228110 and 
references therein to see what I mean), but anyway. If 
somebody comes with a clean and minimalist patch I would 
accept it.

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Just to keep people updated, I have done something to have consolekit used in
xdm, see Bug 237621. If this solution is retained it will certainly be easily
transposed to wdm (by using only the consolekit related stuff, since there is
already a desktop selection).

I found a workaround, which can be used before this gets fixed:
I do not start the window manager directly, but with this wrapper script:


#!/bin/sh
exec ck-launch-session dbus-launch --exit-with-session icewm-session


(replace "icewm-session" by the window manager or desktop environment of your choice, then put the wrapper script name into /etc/wdm/wdm-config, wdmWm option)