Re: dynamic /bin /sbin

[Peter da Silva <peter-dragonfly@xxxxxxxxxxx>]

nflybsd.org> <3f219ddd$0$268$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <3f219ddd$0$268$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 32
Message-ID: <3f21a76b$0$269$415eb37d@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.