Logging activity

Kevin Darcy kcd at daimlerchrysler.com
Fri Aug 31 20:04:25 UTC 2001


Barry Margolin wrote:

> In article <9montn$np7 at pub3.rc.vix.com>,
> Kevin Darcy  <kcd at daimlerchrysler.com> wrote:
> >Huh? What does starting named directly from init have to do with data size
> >limits?
>
> When you reach the data size limit, the process exits.  You need some
> mechanism to restart it when that happens, and respawn is being suggested
> as that mechanism.

Ugh. Okay. I see that now. It just rubs me the wrong way to start a
mission-critical process *expecting* it to crash and burn. I would only do that as
an absolute last resort (I'd rather beg borrow or steal another machine to split
the load), so this "option" never occurred to me.

> Note that if you do this, you also have to make it run in the foreground,
> rather than backgrounding itself as a daemon.  Otherwise, init will respawn
> named processes continuously.  I know that named runs in the foreground if
> given the -d (debug) option; is there a way to do it without enabling
> debugging?

-f

> > You can set data size limits directly within named.conf, or you
> >could set them in whatever rc script starts named. Setting named as
> >"respawn" might backfire badly if there's some persistent error that causes
> >named to crash (although most modern init's will eventually stop trying to
> >respawn it).
>
> This is true no matter what mechanism you use to restart named
> automatically when it aborts.  The alternative is to have your monitoring
> system notify someone whenever it detects that named isn't running, so that
> they can investigate and restart it manually.  But if you've set your
> datasize limit low, so that it aborts frequently, this could be extremely
> inconvenient.

Another option is to upgrade to BIND 9.2, which supposedly deals much more
gracefully with out-of-memory conditions.


- Kevin




More information about the bind-users mailing list