From owner-freebsd-hackers Fri Jun 15 16:51:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp7ve.mailsrvcs.net (smtp7vepub.gte.net [206.46.170.28]) by hub.freebsd.org (Postfix) with ESMTP id 7372837B403 for ; Fri, 15 Jun 2001 16:51:08 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-151-198-117-21.nnj.dialup.bellatlantic.net [151.198.117.21]) by smtp7ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id XAA33407613; Fri, 15 Jun 2001 23:50:57 GMT Message-ID: <3B2A9F60.A12AB917@bellatlantic.net> Date: Fri, 15 Jun 2001 19:50:56 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: tlambert2@mindspring.com Cc: Robert Withrow , Cyrille Lefevre , freebsd-hackers@FreeBSD.ORG Subject: Re: import NetBSD rc system References: <200106141357.JAA27316@pobox.engeast.BayNetworks.COM> <3B29B98E.DAF2ABE4@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Robert Withrow wrote: > > > > clefevre-lists@noos.fr said: > > :- oops, rc2 isn't started. too bad. > > > > I think that is exactly the desired design. The > > RC *system* starts things correctly, but the manager, > > *bypassing* the RC *system* can start and stop things > > exactly as he wished. For debugging or whatever. > > > > I'd argue that if you want to start/stop a *subtree*, you > > should ask the RC *system* to do that somehow. > > Run levels or run states? > > It would be damned useful, for every embedded system I've > ever used FreeBSD for (four now, but who's counting?) to > be able to say: How about keeping the state of the system as empty files in a subdirectory, say, /etc/rcstate.d. This directory would be cleaned up at boot time and then as each of the service startup script is run (and completed successfully), an empty file with the same name would be created in this directory. Reversely, when a service shutdown script is completed (or started ?), the state file is removed. This will allow to define the run states easily as empty rc scripts containing only dependency information in them. Of course, an interesting question is what to do if a shutdown script fails: this may leave the service running or leave it only partially running and thus non-functional. This can be solved by introducing the states "startup or shutdown in progress" and "unknown, possibly broken". -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message