dynamic /bin /sbin

[Richard Coleman]

nflybsd.org>
In-Reply-To: <3f2199cc$0$268$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 29
Message-ID: <3f219ddd$0$268$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 24.98.233.138
X-Trace: 1059167710 crater_reader.dragonflybsd.org 268 24.98.233.138
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:341

Peter da Silva wrote:

> Indeed. The design of the name service needs to be robust, but this
> is just a special case of a general design consideration for any
> server based operating system. If a server dies, then you need to
> make allowances for it: detect it and restart the server, detect
> it and start a fallback server, detect it and flag it so the userapi
> can switch to a fallback mechanism, and so on.
> 
> As Dragonfly evolves, we're likely to run into this issue over and
> over again, we need to think of the general case and the best way to
> handle it. One thing I do in server-based applications I write is to
> have a simple application manager (similar to the System V init) that
> has a table of servers to start, how to tell if they're still running
> (usually because they exit), and what to do when they exit or emit a
> status that indicates they want to exit.

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).

Richard Coleman