From nobody@FreeBSD.org  Fri Apr  2 17:52:51 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 65E7B106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  2 Apr 2010 17:52:51 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 3A3ED8FC14
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  2 Apr 2010 17:52:51 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o32HqoJh006653
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 2 Apr 2010 17:52:50 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o32HqoDq006652;
	Fri, 2 Apr 2010 17:52:50 GMT
	(envelope-from nobody)
Message-Id: <201004021752.o32HqoDq006652@www.freebsd.org>
Date: Fri, 2 Apr 2010 17:52:50 GMT
From: Martin Birgmeier <martin.birgmeier@aon.at>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [patch] /usr/local/etc/rc.d/hald startup delay problem
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         145301
>Category:       ports
>Synopsis:       [patch] sysutils/hal: /usr/local/etc/rc.d/hald startup delay problem
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    gnome
>State:          suspended
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Apr 02 18:00:17 UTC 2010
>Closed-Date:    
>Last-Modified:  Tue Jul 20 20:36:36 UTC 2010
>Originator:     Martin Birgmeier
>Release:        7.2, 7.3, 8.0
>Organization:
MBi at home
>Environment:
FreeBSD gandalf.xyzzy 7.3-RELEASE FreeBSD 7.3-RELEASE #2: Wed Mar 31 19:49:46 CEST 2010     root@gandalf.xyzzy:/d/14.1/OBJ/FreeBSD/RELENG_7_3_0_RELEASE/src/sys/XYZZY  i386
>Description:
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.

>How-To-Repeat:
Try to run the X server before getty starts (using a script in /usr/local/etc/rc.d, usually).

>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:

--- sysutils/hal/files/hald.in.ORIG	2010-03-27 08:59:59.000000000 +0100
+++ sysutils/hal/files/hald.in	2010-04-02 19:26:15.000000000 +0200
@@ -25,7 +25,7 @@
 
 stop_postcmd="hald_postcmd"
 start_precmd="hald_precmd"
-start_cmd="hald_start"
+# start_cmd="hald_start"
 
 local_force_depend()
 {


>Release-Note:
>Audit-Trail:

From: Martin Birgmeier <Martin.Birgmeier@aon.at>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: ports/145301: [patch] /usr/local/etc/rc.d/hald startup delay
 problem
Date: Fri, 02 Apr 2010 20:30:05 +0200

 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 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Apr 5 01:00:53 UTC 2010 
Responsible-Changed-Why:  
Fix synopsis and assign. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=145301 
State-Changed-From-To: open->suspended 
State-Changed-By: mezz 
State-Changed-When: Tue Jul 20 20:35:04 UTC 2010 
State-Changed-Why:  
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. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=145301 
>Unformatted:
