Subject: Re: re-reading /etc/resolv.conf on change
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Bruce J.A. Nourish <email@example.com>
Date: 01/02/2004 17:00:23
On Thu, Jan 01, 2004 at 03:12:39PM -0500, Greg A. Woods wrote:
> > > Then, if you alter resolv.conf, run a program announcing "I've altered
> > > resolv.conf" to the world and all will be well! :)
> > This touches on a general problem that exists in all the free Unices:
> > user <-> kernel communication. There is simply no general, event based
> > infrastructure to communicate changes in the system state.
> Huh? /etc/resolv.conf edits are not kernel related. There's no kernel
> state change to communicate.
Granted. But it _is_ an important, system wide, change in state.
> This is only a userland to userland issue. SIGHUP is your friend.
SIGHUP is a blunt weapon: a process that recieves SIGHUP has no idea
what changed until it repolls all of it's configuration data.
Also, most interactive processes do not respond that way to SIGHUP at
all: they quit instead! I believe this is the historically correct way
> [interesting piece on OS theory and ioctls()]
This is all true, but beside the point. What I'm advocating is something
A new char device, (say /dev/sysevent). An interested process open's
this and then select's on it (or uses kqueue). Then, when interesting
things happen (device add/remove, network link up/down, etc.), the
processes in question recieve a message telling them so, and they
take the appropriate action.
A process with sufficient priviliges would be able to write events to
the file, to notify of system-wide, non-kernel changes in state (like
We could then solve this specific problem by having the resolver use
kqueue to test /dev/sysevent for a new resolv.conf, and reload it
> Is [NIH syndrome] contagious or something?
NIH! NIH! NIH!
And besides, didn't I just read you vaguely complain about TNF's "ultra-
conservative approach to things like this?" Where "this" is an entirely
new regex library?
Bruce J.A. Nourish <firstname.lastname@example.org> http://bjan.freeshell.org