FreeBSD's startup command for hald, /usr/local/etc/rc.d/hald, uses a custom start_cmd which waits up to 60 seconds for getty to start. This has a bad interaction when the X server is not started from getty, but using a (custom) startup script. In this case, the X server starts *before* getty, but the hald waits until *after* getty has started. This means that the X server does not see the devices offered by hald. Before I finally tracked down the cause, I had the following in my X startup script in order to ensure that hald was running before the X server started: i=0 while [ $i -lt 120 ] && ! /usr/local/bin/lshal > /dev/null 2>&1 do if [ $i -eq 0 ] then echo -n ' (please wait)' else echo -n . fi sleep 3 : $(( i = i + 3 )) done This of course only worked because it waited *longer* than the maximum delay in /etc/local/etc/rc.d/hald (fortunately, the latter *did* include such a maximum (at 60 seconds), otherwise the script above would have timed out (after 120 seconds)). The fix is simple: simply get rid of the custom startup command in /usr/local/etc/rc.d/hald. Fix: The bandaid patch is attached. Of course, the whole body of the start_cmd can also be deleted, but this should be checked by whoever wrote this in the first place - I do not know for what reason the wait for getty was introduced originally. Patch attached with submission follows: How-To-Repeat: Try to run the X server before getty starts (using a script in /usr/local/etc/rc.d, usually).
Oh well... I have been looking for answers to this delay problem for ages, but never found anything much helpful. Now that I have the "fix", I find http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005690.html right away... This whole thing is an abominable hack! At the end of the thread cited above, there is an alternative solution (basically starting hald twice). Maybe that should be implemented. But with kdm started from rc.d, I am asking myself whether the console-kit-daemon does anything interesting at all. And just now I have also found /usr/local/kde4/etc/rc.d/kdm4 - I always looked in /usr/local/etc/rc.d before, never found it, and therefore used my own script. Hmmm. I guess now I only need to find where all this is documented. For the time being, I'll still try running without start_cmd in rc.d/hald.
Responsible Changed From-To: freebsd-ports-bugs->gnome Fix synopsis and assign.
State Changed From-To: open->suspended As you have figured it out why hal has all of hacks in it. Mark it as suspended, that way it will remind us when we don't need hack anymore.