dynamic /bin /sbin
Peter da Silva
peter-dragonfly at taronga.com
Fri Jul 25 14:52:14 PDT 2003
nflybsd.org> <3f219ddd$0$268$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <3f219ddd$0$268$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 32
Message-ID: <3f21a76b$0$269$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 206.109.159.11
X-Trace: 1059170157 crater_reader.dragonflybsd.org 269 206.109.159.11
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:344
Richard Coleman wrote:
> Yeah, something like Dan Berstein's "daemontools" would be nice to have
> in the base system. Now, I'm NOT advocating importing daemontools into
> the base. Anything related to Dan seems to provoke strong emotion, so I
> don't want to start that argument. But the kernel of the idea is right.
> The number of daemons running on modern systems keeps growing. No one
> wants to use inetd anymore (that's a whole other discussion). So,
> sysadmins need tools to actively manage and monitor all these processes.
> In some sense, it's the logical extension of the reasons that people
> want RCNG (more orthogonal management of resources).
I can see if I can get permission to release one of the managers
I've written. Though even a fairly complex one is pretty small and
simple to implement if it's designed properly.
A simplified version of one of my config files:
ns:server:respawn,prio=2:/sbin/servers/hosts_server
ns:server:respawn,prio=1,grace=30s:/usr/sbin/servers/bind_server
ns:server:respawn,prio=0:/usr/sbin/servers/nsswitch_server
ns_check:monitor:freq=30s,server=ns:/sbin/monitors/resolve localhost
So when the system comes up it loads and runs the nameserver with
the lowest priority. If it starts dying (at all, or 'too frequently':
say we discover the bind_server has a habit of dying after a few
hours, maybe even deliberately, so we assume it's OK if it doesn't
die within 30s) or ns_check can't resolve localhost, it marks that
server "dead" and tries to run the best remaining server.
Implementing this in a reasonably paranoid fashion shouldn't take
more than a few hours.
More information about the Kernel
mailing list