From owner-freebsd-hackers Thu Jun 14 14:39:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from stlaurent.mindstep.com (stlaurent.mindstep.com [216.18.127.174]) by hub.freebsd.org (Postfix) with ESMTP id 8F64037B403 for ; Thu, 14 Jun 2001 14:39:07 -0700 (PDT) (envelope-from patrick@netzuno.com) Received: from grouch (grouch.local.mindstep.com [192.168.0.10]) by zunobox.local.mindstep.com (Postfix) with SMTP id D3A129913 for ; Thu, 14 Jun 2001 17:39:07 -0400 (EDT) From: "Patrick Bihan-Faou" To: Subject: Re: import NetBSD rc system Date: Thu, 14 Jun 2001 17:38:36 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 ""Koster, K.J."" wrote in message news:<59063B5B4D98D311BC0D0001FA7E452205FD9CAE@l04.research.kpn.com>... > Dear All, > > > > > To do some of the hierarchal start/stop at runtime stuff, you > > really need > > a stateful rc system that stores its start/stop state in > > /var/run/rc.d or > > the like. In this way, the system could track various > > activities and know > > which dependencies were already started. > > > How about /var/run/{$deamon}.pid? > Or better yet, leave each independent script the responsibility of knowing its own state. I am assuming that the various rc.d scripts must have well defined entry points (i.e. start|stop|restart), adding a "status" entry point would solve this issue. I implemented something more or less similar to the netbsd rc system once (I did it in perl however). This system tracked the dependencies and the states of each services. And the state tracking proved to be the worst part. This is why I would suggest to leave the service state tracking to the service scripts themselves. This is far easier to implement at that level than at a global level. Of course the "status" (or whatever name is suitable) call must have well defined return values; 0 -> running and happy 1 -> not started ... Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message