Date: Tue, 17 Nov 1998 19:07:38 -0800 From: Jamie Lawrence <jal@ThirdAge.com> To: Jacques Vidrine <n@nectar.com>, Nik Clayton <nik@nothing-going-on.demon.co.uk> Cc: hackers@FreeBSD.ORG Subject: Re: /etc/rc.d, and changes to /etc/rc? Message-ID: <3.0.5.32.19981117190738.00b04bd0@204.74.82.151> In-Reply-To: <199811180255.UAA01561@spawn.nectar.com> References: <19981117235348.41074@nothing-going-on.org> <19981115235938.22908@nothing-going-on.org> <19981117210138.03327@nothing-going-on.org> <199811172241.QAA00519@spawn.nectar.com> <19981117235348.41074@nothing-going-on.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 08:55 PM 11/17/98 -0600, Jacques Vidrine wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >These are good points, so I hope you don't mind me copying them back >to -hackers where my original message was posted. > >On 17 November 1998 at 23:53, Nik Clayton <nik@nothing-going-on.demon.co.uk> wrote: >> On Tue, Nov 17, 1998 at 04:41:03PM -0600, Jacques Vidrine wrote: >> > Let's see ... you will be adding complexity. Please specify >> > the payback. >> >> 1. When killing system daemons (i.e., inetd, sendmail, named, lpd, and >> so on) no need to try and find the right PID, playing with ps, grep, >> and friends. This is a win when explaining the process to someone >> newer to Unix than most members of this list, particularly because >> the process is the same each time. They don't (yet!) need or want to >> understand what the script is doing, that can come later. It also >> makes documentation simpler. > >Unless the user is from a System V world, this will be no simpler >than using ``killall''. I believe that mistakenly using killall on a System V machine after learning the ropes on BSD is an admin rite of passage, and I'd hate to help save anyone from that experience, but that's beside the point... I think the big win here is a common framework for handling what can become highly complex daemon start/stop procedures. One that I've ended up doing is database daemons. Example: you want to kill msql for whatever reason. It serves some fast CGIs that in turn provide functionality to web users at large. A stop procedure for this daemon involves killing the fcgis, killing the DB daemon, moving a "service unavailable" page into the docroot (or some other mechanism for end user notification), and possibly other tasks. Right now, everyone who builds a script for this does it differently. With a rc.d framework, this sort of problem becomes much more standardized, as admins will tend to build them into that framework. I think the real tradeoff is between homegrown complexity that often is under documented and homegrown complexity that at least follow conventions that are easy to follow. This is one of the few places I actually prefer Solaris to FreeBSD (run state madness notwithstanding). My coupla pfinnig. -j To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.5.32.19981117190738.00b04bd0>