Date: Thu, 17 Sep 1998 15:32:23 +0200 From: Martin Cracauer <cracauer@cons.org> To: Alfred Perlstein <bright@hotjobs.com>, Martin Cracauer <cracauer@cons.org> Cc: current@FreeBSD.ORG Subject: Re: Proposed change to rc.d startup Message-ID: <19980917153223.A25420@cons.org> In-Reply-To: <Pine.BSF.3.96.980917090912.17139B-100000@bright.fx.genx.net>; from Alfred Perlstein on Thu, Sep 17, 1998 at 09:20:57AM -0500 References: <19980917140553.A25322@cons.org> <Pine.BSF.3.96.980917090912.17139B-100000@bright.fx.genx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In <Pine.BSF.3.96.980917090912.17139B-100000@bright.fx.genx.net>, 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 <cracauer@cons.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980917153223.A25420>