Date: Tue, 23 Oct 2001 16:13:09 +0100 (BST) From: Jan Grant <Jan.Grant@bristol.ac.uk> To: Guido van Rooij <guido@gvr.org> Cc: Dag-Erling Smorgrav <des@ofug.org>, Will Andrews <will@physics.purdue.edu>, arch <arch@FreeBSD.org> Subject: Scoping /etc/rc.d/* status Was: New rc.d init script roadmap Message-ID: <Pine.GSO.4.31.0110231607470.24903-100000@mail.ilrt.bris.ac.uk> In-Reply-To: <20011022154615.A42579@gvr.gvr.org>
index | next in thread | previous in thread | raw e-mail
On Mon, 22 Oct 2001, Guido van Rooij wrote: > On Fri, Oct 19, 2001 at 12:12:31AM +0200, Dag-Erling Smorgrav wrote: > > > > This issue is sufficiently complex that I actually think a small > > well-thought-out special-purpose script language would be better > > suited to this task that a bunch of shell scripts + rcorder, but > > that is probably a far too politically controversial suggestion. > > > > (it's all a matter of interdependent objects on which you can perform > > various operations, so a Real Hacker would come up with a lightweight > > object-oriented script language that could not only manage the startup > > sequence but replace make(1) as well. > > > > Since checking is done differently per service, it makes most sense > to me to put the checks in the service scripts. > That means that non-standard services like ipfilter must implement > there own ipfilter_cmd scripts and skip the start command if alread > started. A word about checking status. It seems to me that there are increasing complications in the situations rc.d scripts might be expected to cope with: 1. services only started and stopped through rc.d scripts; nothing ever crashes 2. services started through rc.d; things occasionally break (daemons crash) 3. services started and stopped ad hoc by the user 4. user attempts to deliberately pervert rc.d system's operation (removing PID files, etc) We clearly want to cope with at least (1), and would like scripts to cope in most situations with at least (2) and (3) reasonably gracefully. What we can guarantee for (4) is little or nothing in the general case. So it might be argued that for stuff like IPF, "faking up" a PID/status file and relying on that to hold the "running/inactive" status is "sufficiently robust". jan -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk On modesty: whoever said "it's hard being perfect" obviously wasn't me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the messagehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.31.0110231607470.24903-100000>