Date: 19 Oct 2001 00:12:31 +0200 From: Dag-Erling Smorgrav <des@ofug.org> To: Will Andrews <will@physics.purdue.edu> Cc: arch@FreeBSD.org Subject: Re: New rc.d init script roadmap Message-ID: <xzpvghc8unk.fsf@flood.ping.uio.no> In-Reply-To: <20011018164026.A25747@squall.waterspout.com> References: <Pine.LNX.4.33.0110181320120.1612-100000@smtp.gnf.org> <xzpn12oacc5.fsf@flood.ping.uio.no> <20011018163033.C57251@squall.waterspout.com> <xzp4rowaasr.fsf@flood.ping.uio.no> <20011018164026.A25747@squall.waterspout.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Will Andrews <will@physics.purdue.edu> writes:
> On Thu, Oct 18, 2001 at 11:38:28PM +0200, Dag-Erling Smorgrav wrote:
> > What pidfile is /etc/rc.d/ipfilter going to leave behind? Part of the
> > sequence for starting ipfilter is "ipf -E -Fa", so you defintely do
> > *not* want to run it by accident.
> Well, obviously there will be some different interpretations of
> the "start", "stop", "restart", etc. arguments. But everything
> that starts a daemon should have a corresponding pidfile.
My point is that the service you want to start may depend on another
service that just configures something, but doesn't start a daemon
(ipfilter is an example), so you can't always just check the pidfile
to see if a service has ben started. Also, the presence of a pidfile
does not necessarily mean the process is actually running (rc.subr is
smart enough to check if the PID listed in the pidfile exists, but
that's no guarantee either). Currently, NetBSD's rc system has no way
of checking if ipfilter is already configured before starting it, but
ipfilter is a prerequisite for network, which is a prerequisite for
just about everything, including nfsd, which was the example Gordon
brought up, so trying to start nfsd "and all its dependencies" will
flush all ipfilter rules, including dynamic rules, which means killing
all established connections if you're using stateful inspection. Not
the kind of thing you'd enjoy discovering the hard way by typing
"/etc/rc.d/nfsd start" in an ssh session to a server that's on the
other side of town.
(it'll also flush the routing table as a side effect of starting the
"network" service, btw, so you're screwed even if you don't use
stateful inspection)
This issue is sufficiently complex that I actually think a small
well-thought-out special-purpose script language would be better
suited to this task that a bunch of shell scripts + rcorder, but
that is probably a far too politically controversial suggestion.
(it's all a matter of interdependent objects on which you can perform
various operations, so a Real Hacker would come up with a lightweight
object-oriented script language that could not only manage the startup
sequence but replace make(1) as well.
...
why are you all looking at me like that?)
DES
--
Dag-Erling Smorgrav - des@ofug.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpvghc8unk.fsf>