From owner-freebsd-arch Tue Oct 23 8:14:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by hub.freebsd.org (Postfix) with ESMTP id A1B4637B403 for ; Tue, 23 Oct 2001 08:14:26 -0700 (PDT) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 23 Oct 2001 16:14:18 +0100 Received: from cmjg (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 15w3Es-0001zo-00; Tue, 23 Oct 2001 16:13:10 +0100 Date: Tue, 23 Oct 2001 16:13:09 +0100 (BST) From: Jan Grant X-X-Sender: To: Guido van Rooij Cc: Dag-Erling Smorgrav , Will Andrews , arch Subject: Scoping /etc/rc.d/* status Was: New rc.d init script roadmap In-Reply-To: <20011022154615.A42579@gvr.gvr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 message