From owner-freebsd-current Tue Nov 17 16:00:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA14321 for freebsd-current-outgoing; Tue, 17 Nov 1998 16:00:13 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA14272 for ; Tue, 17 Nov 1998 16:00:06 -0800 (PST) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.8.8/8.8.8) id XAA09059; Tue, 17 Nov 1998 23:57:09 GMT (envelope-from nik) Message-ID: <19981117235709.20735@nothing-going-on.org> Date: Tue, 17 Nov 1998 23:57:09 +0000 From: Nik Clayton To: current@FreeBSD.ORG Subject: /etc/rc.d, and changes to /etc/rc? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Folks, [ Originally posted to -hackers. Forwarded to -current at Robert Nordier's request, apparently fewer developers than I thought read -hackers. Reply-to *not* set, I can read replies in either -hackers or -current, and this is probably -current material as much as it is -hackers ] During the day job, I use Solaris. This is not, in and of itself, a bad thing. Solaris uses run levels. I don't particularly like them, but I tolerate them. I *don't* want to bring run levels (or even, if Terry's reading, run states) to FreeBSD. The one useful feature I've found with run [levels|states] as implemented on Solaris is the /etc/init.d directory. For those that don't know, this contains 'n' scripts, one per 'service', that take 'start' and 'stop' parameters. If you want to stop Sendmail, it's sh /etc/init.d/sendmail stop No need to poke around with ps, grep, and friends to determine the PID to kill, no wondering about whether or not there's a lock file you might need to clean up afterwards, and so on. It helps save a little time, and is probably easier for newcomers to understand as well. We already have the beginning of a system like this for ported software, with the ${PREFIX}/etc/rc.d directory. What are people's thoughts on doing the same thing to the base system? In essence, this would involve (on a case by case basis) going through the daemons started in /etc/rc*, building a script to start/stop the daemon, and changing the code in /etc/rc* to call these scripts instead. NOTE: The order in which scripts would be called by /etc/rc* would not be determined by the script name, there would be none of this silliness with S20foo and K50bar, ordering is still determined by /etc/rc* All I want to do is abstract out the daemon start/stop process a little more. Down the road, this could bring other benefits as well; - For those that like run levels/states, it becomes easier for them to create a port with a new version of init that implemented them. People that want run levels install the port, people that don't, don't. - It makes it easier to install replacements for programs that are in the base system. If sendmail was started from /etc/rc.d/smtp.sh, the first thing smtp.sh could check for is the existence of /usr/local/etc/rc.d/smtp.sh, and call that instead if it existed. Replacing sendmail with qmail or vmailer then becomes a little easier. - Simplifies documentation. When explaining how to stop a system process, you don't need to explain ps, grep, kill, awk/cut, backticks, and pipelines. You just say "Do it like this", and explain the magic behind it at a later point. I realise this is a religious issue, and one of those things people like to get all excited about. However, I've just seen a message from Jordan suggesting the ordering be changed in host.conf, and *no one* objected. I figured I'd jump in quickly, before they stop putting Prozac in the water. N -- C.R.F. Consulting -- we're run to make me richer. . . To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message