Re: rndc: connect failed: connection refused
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
At 19:44 17/10/2004, Steve Sandau wrote:[color=blue]
><successful startup sniped>[color=green][color=darkred]
> >>if I then restart using the command
> >>/etc/rc.d/init.d/named restart
> >>I just get
> >>Oct 17 18:21:31 dedi5 named: starting BIND 9.2.1 -u named
> >>Oct 17 18:21:31 dedi5 named: 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[/color]
> > -d debug-level Set the daemons debug level to debug-level.
> > Debugging traces from named become more verbose[/color]
> as the[color=green]
> > 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.