I have defined de 'rand_irqs' settings in rc.conf as you suggested but
unfortunately the result was the same.

Meanwhile I setup a fresh installation, of the new FreeBSD 5.2.1 release
with the BIND 8.3.7, in other box.
I setup the BIND and the system with the same settings as the other and
defined to start BIND on boot.
The result was that the boot process was ok (it took the normal time) and
the output of "ndc status" was: "The server is up and running" ;-))))
instead of the boring message "server is initializing itself".

My question is: what solve the problem, the new FreeBSD 5.2.1 or the BIND
How can I solve this strange behaviour in the FreeBSD 4.9/BIND 8.3.6 system?

Many Thanks,

-----Original Message-----
From: Matthew Seaman [mailto:[EMAIL PROTECTED] 
Sent: sexta-feira, 21 de Maio de 2004 13:15
To: Nuno César Pires
Subject: Re: Help to start BIND on boot

On Fri, May 21, 2004 at 12:07:25PM +0100, Nuno César Pires wrote:

> I'm setting up a BIND/DNS server (recursive) and I'm facing a problem when
> try to start the "named" automatically on boot (named_enable="YES" in
> rc.conf):
> First I noticed that the boot process takes a very long time in the
> "Starting Standard Daemons" phase.
> After boot I have looked to the named messages and apparently it was
> everything ok i.e.:
> First message:              "starting (etc/namedb/named.conf). named
> 8.3.6-REL ....."
> Second message:          "limit files set to fdlimit (1024)"
> Third message:              "Ready to answer queries."
> But the problem is the output of "ndc status": (server is initializing
> itself) and then nothing happen.
> Starting or restarting the named manually works just fine, the "ndc
> output is "server is up and running" and the queries answers are as
> expected.
> The result after comment the kern_securelevel="2" and
> kern_securelevel_enable="YES" lines in the rc.conf and reboot was the same
> as described above.
> The ROOT SERVERS file was updated and there is a permanent network
> connection
> Releases:
> FreeBSD 4.9
> BIND 8.3.6

I usually see this effect with things like sshd(8), but it could
affect BIND as well.  I wonder if named(8) is blocking trying to read
/dev/random to obtain a quantity of random data.  If the system does
not have sufficient suitable random data available, it will wait until
it has acquired enough before replying.  Sources of randomness are
things like timing the gaps between key presses or between the arrival
of network packets -- either of which may not be very effective around
reboot time.

Check your setting for 'rand_irqs' in /etc/rc.conf -- you need to set
it to a list of IRQs that fire quite frequently and that have timings
that can be used to harvest randomness from.  To get a list of
suitable IRQs use:

    % vmstat -i

So for instance on my system that returns:

    interrupt                   total       rate
    acpi0 irq9                      1          0
    pcm0 irq10                  39644          0
    mux irq11                12139824         77
    mux irq15                  854820          5
    atkbd0 irq1                 49505          0
    psm0 irq12                 389549          2
    sio1 irq3                   81928          0
    clk irq0                157097139       1000
    rtc irq8                 20105805        128
    Total                   190758215       1214

Choose the IRQs that fire most often, but not the clk (clock) or rtc
(real time clock) IRQs -- as those fire at regular intervals.  In this
case good choices are irq1 (atkbd -- the keyboard), irq11 and irq15
(mux -- the TCP multiplexor (ie network traffic)), irq12 (psm -- the



Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK

CONFIDENCIALIDADE: Esta mensagem e quaisquer documentos em anexo são
confidenciais. Se não for o destinatário desta mensagem, agradecemos que
avise imediatamente o remetente e que a elimine sem a reproduzir, armazenar
ou divulgar a qualquer entidade.

CONFIDENTIALITY: This  e-mail  and  any attachments are confidential and may
be privileged. If  you are not a named recipient, please notify the sender
immediately and do not disclose the contents to another person, use it for
any purpose or store or copy the information in any medium.
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to