Date: Tue, 24 Oct 2000 04:45:56 -0500 (CDT) From: Mike Meyer <mwm@mired.org> To: Alexey Dokuchaev <danfe@inet.ssc.nsu.ru> Cc: Garrett Rooney <rooneg@electricjellyfish.net>, freebsd-current@FreeBSD.ORG Subject: Re: new rc.network6 and rc.firewall6 Message-ID: <14837.23124.964605.901875@guru.mired.org> In-Reply-To: <Pine.LNX.4.10.10010241615270.32319-100000@inet.ssc.nsu.ru> References: <14837.19218.317368.924510@guru.mired.org> <Pine.LNX.4.10.10010241615270.32319-100000@inet.ssc.nsu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexey Dokuchaev writes: > > Well, we *already* have over a dozen /etc/rc.* files on -current. And > > we *don't* have the advantage of a consistent interface to control all > > the functions in /etc/rc. If you break things up, then if you need to > > restart the mail server, just go "/etc/rc.d/sendmail restart". dhcpd? > > "/etc/rc.d/sendmail/dhcpd restart". Etc. > Actually, the point is that writing TONS of scripts to get your work > done (that's what Linux world does) always pissed me off. You have a > shell script that is in fact a wrapper for another shell script, and like > this in turn it goes on and on and on again. Icky! :-) I don't like > how Linux smells. Well, I don't like Linux much either. On the other hand, I hate dealing with a lots of little things all of which are just slightly different from each other even more - and the latter is what you get from /etc/rc. > Why can't I simply write kill -1 `cat /var/run/sendmail.pid`? I don't > consider it being sagnificantly longer than writing /etc/rc.d/sendmail > restart. After all, if your typing speed is good enough, it doesn't > really matter whether you type in 30 or 20 chars. You can still do that. However, do you know how to get everything listed in /etc/defaults/rc.conf to reread it's config file? With the approach being advocated, the answer is "yes" - even if you don't know whether or not the daemon in question *has* a config file. That's the thing I like about all those scripts (SysV, linux, whatever) - I didn't have to deal with cruft like that. Yeah, for some things, this means you wind up running a script that's a wrapper for the vendor-provided script to make it meet your standards. If you really hate that, ignore the vendors script and talk directly to the application - but they get little enough use that I'd rather use the vendor's API and let it be wasteful. After all, if they got a lot of use, having different interface wouldn't be a problem. <mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14837.23124.964605.901875>