From owner-freebsd-alpha Tue Dec 10 1:20: 5 2002 Delivered-To: freebsd-alpha@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34B0137B401 for ; Tue, 10 Dec 2002 01:20:04 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE62B43EA9 for ; Tue, 10 Dec 2002 01:20:03 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id gBA9K3x3052379 for ; Tue, 10 Dec 2002 01:20:03 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id gBA9K3Sv052378; Tue, 10 Dec 2002 01:20:03 -0800 (PST) Date: Tue, 10 Dec 2002 01:20:03 -0800 (PST) Message-Id: <200212100920.gBA9K3Sv052378@freefall.freebsd.org> To: freebsd-alpha@FreeBSD.org Cc: From: "Sergey Amelyuschenko" Subject: Re: alpha/45947: init does not invoke getty Reply-To: "Sergey Amelyuschenko" Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR alpha/45947; it has been noted by GNATS. From: "Sergey Amelyuschenko" To: "Andrew Gallatin" Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: alpha/45947: init does not invoke getty Date: Tue, 10 Dec 2002 12:11:49 +0300 Hi Drew! > Hmm.. > > 2 ideas: > > 1) Perhaps it still thinks that its running a startup script and has not > made it fully multi-user. Have you installed or upgraded any ports > recently? something in /usr/local/etc/rc.d/foo.sh started so that it > does not go into the background might block init. > > > 2) init has gone totally insane. I'd stick some printfs > in transition_handler(), and in multi_user(), and in clean_ttys(). > So as to try to see what's happening when the signal is delivered. Wow! You are incredible! Your first idea was right! I had /usr/local/etc/rc.d/mysql-server.sh script hanging around from old version of mysql. This script did not go into the background during boot. Now I have upgraded mysql-server.sh and everything works as expected! Anyway, this experience raises the question of reliability of boot process. That is, by fooling around with /usr/local/etc/rc.d it is possible to prevent init from going multiuser. Is it possible to implement some anti-foot-shooting technique? I mean if script was not started in some timeframe just kill it and go on to the next one? Thanks again for your help! Sergey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message