Date: Thu, 6 Jul 2000 22:30:57 +0200 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: freebsd-stable@FreeBSD.ORG Subject: Re: HEADS UP: /etc/rc.shutdown calls local scripts now Message-ID: <20000706223057.I5945@speedy.gsinet> In-Reply-To: <Pine.BSF.4.21.0007061210020.85509-100000@dragonstar.dhs.org>; from jonsmith@dragonstar.dhs.org on Thu, Jul 06, 2000 at 12:14:54PM -0500 References: <20000706102309.D20588@dan.emsphone.com> <Pine.BSF.4.21.0007061210020.85509-100000@dragonstar.dhs.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 06, 2000 at 12:14 -0500, Jonathan Smith wrote:
>
> Quickie question:
>
> By implementing the 'start' and 'stop' in the local scripts,
> how much should one _expect_ their systems bootup and slow down
> times to take?
Not at all, IMO. Or at least not in a measurable way. I don't
see the (significant) difference in burdon between an if clause
sequence in an /etc/rc.* and a loop over /usr/local/etc/rc.d/*.sh
files. Both places can start daemons in foreground or
background.
I even don't see the slowdown factor in 'echo "$ESC_SEQ_FOR_OK"'
versus 'echo -n "$SERVICE_NAME"'. But I do understand the
difference in that the latter is wasting screen space and shoves
off the screen what one might want to have read. But this
thread's direction was just a joke a few people felt like jumping
in for no real point.
Regarding the 'stop' sequence I feel this to be no pain either.
What's the difference between simply TERMing all processes and
shutting down a service by a script knowing the daemon and
environment better than kill? Right -- the latter has more
chances to work cleanly. And BTW for most cases the stop case
could be just as short. But the shutdown sequence can be obeyed.
And how many scripts are lingering in the local startup dirs?
What's the time penalty we're talking about here? Seconds?
> I, for one, like the functionality, and thought it kinda
> already worked that way (or maybe I _made_ it work that way on
> my machines, cn't remember). I would like solid facts, rather
> than a religious/exagerated discussion.
I don't like thinking back of when I wanted to NFS export
buildworld results to installworld on a different machine: How
do I start an NFS server and client service? And how do I stop
it afterwards? Start /stand/sysinstall, enable the service,
reboot, work some minutes, disable the service in sysinstall,
reboot, continue? Of course I could crawl along the rc scripts
and grab together all the single commands (and I did). But it's
error prone. A simple '/etc/rc.d/nfsserver start' could have
done ...
And for another aspect: Do you always know how to start, stop,
restart, reload, examine, rotate trigger, do whatever to any
service your machine's running? Think of ndc and RunCache and
apachectl and friends -- they're all "masqueraded" versions of
this very mechanism: how to deliver a somewhat unified interface
to the admin for managing services leaving more time and
resources for the real work. I cannot see where this is evil.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000706223057.I5945>