From owner-freebsd-current Thu Sep 17 06:32:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA07545 for freebsd-current-outgoing; Thu, 17 Sep 1998 06:32:57 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from cons.org (knight.cons.org [194.233.237.86]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA07514 for ; Thu, 17 Sep 1998 06:32:50 -0700 (PDT) (envelope-from cracauer@cons.org) Received: (from cracauer@localhost) by cons.org (8.8.8/8.7.3) id PAA25440; Thu, 17 Sep 1998 15:32:23 +0200 (CEST) Message-ID: <19980917153223.A25420@cons.org> Date: Thu, 17 Sep 1998 15:32:23 +0200 From: Martin Cracauer To: Alfred Perlstein , Martin Cracauer Cc: current@FreeBSD.ORG Subject: Re: Proposed change to rc.d startup References: <19980917140553.A25322@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: ; from Alfred Perlstein on Thu, Sep 17, 1998 at 09:20:57AM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In , Alfred Perlstein wrote: > y'know the funny thing is that i was thinking of hacking something so that > /etc/rc.conf would have a flag telling to to protect its children from ^C > and such. > > solaris does this, or at least seems to (^C doesn't muck with startup > programs) > > it'd be a nice option for a lab/hostile cluebie enviorment: > > /etc/rc.conf: > nocontrolc = "YES" > > /etc/rc: (right after rc.conf is sucked in) > if [ "x$nocontrolc" = "xYES" ]; then > trap 'echo -n' 2; > fi Hm, I think I have to give you some backgroud here: 1) Our current scheme in the toplevel rc shell is: 2a) On SIGINT, break current command and proceed with the next step. 2b) On SIGQUIT, jump to singleuser mode immedeatly. 2) Your trap 'echo -n' 2; will do exactly nothing, it will return control to the blocking child after echoing nothing, this doesn't enable breaking blocking childs. ==> If you want to recover from a blocking child, but proceed with the next step in rc, you have to fork a subshell that exits on SIGINT (unless you start messing with even more complicated control statements). I'm against having an option for turning off the child killing possibility in any case. Users have to keep their fingers from C-c. If we turn it off, you might never get a prompt on the console. Unless some network login service is already up, you would have to reset without sync, then fix things from singleuser mode. Provided that the problem one child was hanging for is reproduceable. What could people gain from being able to SIGINT or SIGQUIT things at startup that they're not already able to do since they have physical access to the machine? I stay with my original proposal. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message