From owner-freebsd-hackers Tue Nov 17 18:56:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA06942 for freebsd-hackers-outgoing; Tue, 17 Nov 1998 18:56:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cerebus.nectar.com (nectar-gw.nectar.com [204.0.249.101]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA06935 for ; Tue, 17 Nov 1998 18:56:10 -0800 (PST) (envelope-from nectar@nectar.com) Received: (from smap@localhost) by cerebus.nectar.com (8.9.1/8.9.1) id UAA01313; Tue, 17 Nov 1998 20:55:32 -0600 (CST) (envelope-from nectar@nectar.com) Received: from spawn.nectar.com(10.0.0.101) by cerebus.nectar.com via smap (V2.1) id xma001311; Tue, 17 Nov 98 20:55:29 -0600 Received: from spawn.nectar.com (localhost.nectar.com [127.0.0.1]) by spawn.nectar.com (8.9.1/8.9.1) with ESMTP id UAA01561; Tue, 17 Nov 1998 20:55:29 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Message-Id: <199811180255.UAA01561@spawn.nectar.com> X-Mailer: exmh version 2.0.2 2/24/98 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://www.nectar.com/nectar-pgp262.txt From: Jacques Vidrine In-reply-to: <19981117235348.41074@nothing-going-on.org> References: <19981115235938.22908@nothing-going-on.org> <19981117210138.03327@nothing-going-on.org> <199811172241.QAA00519@spawn.nectar.com> <19981117235348.41074@nothing-going-on.org> Subject: Re: /etc/rc.d, and changes to /etc/rc? To: Nik Clayton cc: hackers@FreeBSD.ORG Date: Tue, 17 Nov 1998 20:55:29 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- These are good points, so I hope you don't mind me copying them back to -hackers where my original message was posted. On 17 November 1998 at 23:53, Nik Clayton wrote: > On Tue, Nov 17, 1998 at 04:41:03PM -0600, Jacques Vidrine wrote: > > Let's see ... you will be adding complexity. Please specify > > the payback. > > 1. When killing system daemons (i.e., inetd, sendmail, named, lpd, and > so on) no need to try and find the right PID, playing with ps, grep, > and friends. This is a win when explaining the process to someone > newer to Unix than most members of this list, particularly because > the process is the same each time. They don't (yet!) need or want to > understand what the script is doing, that can come later. It also > makes documentation simpler. Unless the user is from a System V world, this will be no simpler than using ``killall''. > 2. No wondering whether or not there's a lock file lying around that's > been forgotten. Start up scripts in ${PREFIX}/etc/rc.d should take care of this for ports. What lock files are you concerned about in the base system? > 3. Makes updating /etc simpler after a 'make world'. If each script > starts with something like > > if [ -x /usr/local/etc/rc.d/`basename $0` ]; then > exec /usr/local/etc/rc.d/`basename $0` $* > fi > > then you could completely replace sendmail (which would be started > from smtp.sh) by creating a /usr/local/etc/rc.d/smtp.sh script. One > less thing to worry about. I don't understand your point here. If you want to use something other than sendmail, just set sendmail_enable="NO" in rc.conf. > 4. Those that like run levels/run states (I'm not one of them) could > make their own init and other bits and pieces and make it available > as a port. Who cares? If they want ``their own init and other bits and pieces,'' there isn't anything to stop them from doing this today. Maybe I again don't get your point. > This would involve the removal of some knobs from /etc/rc.conf. For > example, "named_enable" would remain, but "named_flags" would be part > of /etc/rc.d/domain.sh (I think naming these scripts after the service > the daemon provides, rather than the name of the daemon itself, is a > win -- the same protocol might be implemented by a variety of differently > named daemons). > > This is not strictly necessary of course. There's no reason that > /etc/rc.d/domain.sh couldn't suck in rc.conf and look for a named_flags > variable. > > Again, at the moment, I'm only thinking of daemons. I'm not touching > things like ifconfig commands, or console maps, or anything like that. I don't see anything broken with the current setup. I much prefer it to System V-like model that you are proposing. If you really believe in this model, I'd suggest making a ``sysvadmin port'' that does what you want. I don't see a lot of users upgrading to FreeBSD 3.0.1 or what have you and being pleased that they now are lost because of a gratuitous change. Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNlI3ITeRhT8JRySpAQF9bwP/Q1Th5HGJUNli/DX01FXVViIoY5Fekkzj aeSFaDzPglY/0HX8Qc/4nASX6euM0izrVJ7bTFDdFZvW12V2D1AcDW0qt6Y6J+7P 6ChSum8lkRINrvEcC0ByBGOJqIRlx5aQ9XXxNl+pJcaC6QOZZih/oiGdNTMirnBf 2yderajQC2U= =vKFm -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message