rndc: connect failed: connection refused

[Greg Mathews]

Thank You all:)

Steve, I have for some reason two named binaries, one /usr/sbin/named and 
the other /usr/local/sbin/named

which named returns the /usr/local path

By adding the path of named to the startup script has solved the problem

Thanks again

Greg

At 19:44 17/10/2004, Steve Sandau wrote:
><successful startup sniped>
> >>
> >>if I then restart using the command
> >>
> >>/etc/rc.d/init.d/named restart
> >>
> >>I just get
> >>
> >>Oct 17 18:21:31 dedi5 named[6183]: starting BIND 9.2.1 -u named
> >>Oct 17 18:21:31 dedi5 named[6183]: using 1 CPU
> >>Oct 17 18:21:31 dedi5 named: named startup succeeded
> >>
> >>If I then do
> >>
> >>ps aux|grep named
> >>
> >>it returns no running processes and named is not running
> >>
> >>I note that it doesn't appear to be loading the conf file when using the
> >>startup script
> >
> >
> >        -d debug-level Set the daemons debug level to debug-level.
> >                       Debugging traces from named become more verbose 
> as the
> >                       debug level increases.
> >        -f     Run the server in the foreground (i.e. do not daemonize).
> >        -g     Run  the  server in  the  foreground and  force all logging
> >               to stderr.
> >
> > I beleave one of these flags will help. Especialy the -d. I've used it
> > to make the process more verbose so I could trace problems and find out
> > where the issue lies when bind wasn't working properly for me. Another
> > tool at your disposal is strace and it'll print output to stdout.
> >
>
>Good ideas. But, before that you might take a look at
>/etc/rc.d/init.d/named and see that is is pointing to the same named
>that 'which named' points to (i.e. that you are running the same
>executable in both cases). You should also look at any arguments that
>/etc/rc.d/init.d/named uses. As an example problem, some versions of
>named will fail with an argument of -g named IIRC.
>
>Steve