From owner-freebsd-ports-bugs@FreeBSD.ORG Fri Apr 2 18:00:18 2010 Return-Path: Delivered-To: freebsd-ports-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C1C9106566C for ; Fri, 2 Apr 2010 18:00:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D5E8B8FC13 for ; Fri, 2 Apr 2010 18:00:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o32I0HtA039820 for ; Fri, 2 Apr 2010 18:00:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o32I0HMU039819; Fri, 2 Apr 2010 18:00:17 GMT (envelope-from gnats) Resent-Date: Fri, 2 Apr 2010 18:00:17 GMT Resent-Message-Id: <201004021800.o32I0HMU039819@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-ports-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Martin Birgmeier Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65E7B106564A for ; 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 ; 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 ; 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 To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: ports/145301: [patch] /usr/local/etc/rc.d/hald startup delay problem X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 18:00:18 -0000 >Number: 145301 >Category: ports >Synopsis: [patch] /usr/local/etc/rc.d/hald startup delay problem >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-ports-bugs >State: open >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: >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: >Unformatted: