This may be the wrong mailing list, but I suspect some of you have experience with this. I installed NSD from the FreeBSD ports collection, and it runs just fine. I made sure that rc.conf has nsd_enable="YES". Yesterday, the system rebooted and NSD didn't come up. It starts fine with "/usr/local/etc/rc.d/nsd start", but it did not come up on reboot. I just rebooted to test again, and it again fails to come up.
Any ideas would be appreciated.
Hello Paul - I'm a dedicated FreeBSD user, and I've been running NSD
for several years now, on several machines. I have yet to have an NSD
problem during reboot. I suggest you:
tail -80 /var/log/messages /var/log/security
... and see if there's any diagnostic output. You may also want to do
a "dmesg" and see if there's anything out of the ordinary (such as a
pid exiting prematurely). The only other obvious reason would be due
to a spelling error in /etc/rc.conf before or on the NSD line (which
means that something before it didn't start also). Observing the
system reboot on the console terminal might yield some clues.
Hope that helps... please keep me posted on what you find!
Regards,
Lew Payne
Not sure about the freebsd initscripts, but on Fedora/RHEL we make sure
that we do an nsdc rebuild if we find any of the zone files is newer
then the nsd.db, otherwise nsd will not start properly. Perhaps this is
what you are seeing now too? Specifically, if you removed a zone and it
is still in the nsd.db.
Paul
Hello Paul - I'm a dedicated FreeBSD user, and I've been running NSD
for several years now, on several machines. I have yet to have an NSD
problem during reboot. I suggest you:tail -80 /var/log/messages /var/log/security
Nothing visible in /var/log/messages
My configuration has:
logfile: "/var/log/nsd.log"
...but there is nothing interesting in there other than when I started it up by hand.
... and see if there's any diagnostic output. You may also want to do
a "dmesg" and see if there's anything out of the ordinary (such as a
pid exiting prematurely).
This is what worries me: there is *nothing* in there, either positive or negative. That's why I don't think that it is even being tried.
The only other obvious reason would be due
to a spelling error in /etc/rc.conf before or on the NSD line (which
means that something before it didn't start also).
As far as I can tell from dmesg, everything else starts fine, other than Apache. Its failure doesn't appear in /var/log/messages, or in the apache error log.
Observing the
system reboot on the console terminal might yield some clues.
Unfortunately, the system is quite remote. I would assume that everything I need is in dmesg. I will try a reboot later with a remote hands person watching the console.
No one's going to like the answer for this: the startup file is /usr/local/etc/rc.d/nsd, not /usr/local/etc/rc.d/nsd.sh. On FreeBSD 6, apparently the ".sh" is required to be seen on startup. I had not tested this earlier because the machine had been up for the better part of a year, and I only installed NSD a few months ago.
I have reported this to the NSD FreeBSD maintainer.
Hi,
Being the NSD FreeBSD port maintainer I noticed this thread on the list (although I still didn’t receive your report to me directly). I have long ago stopped running FreeBSD+NSD setups but have been maintaining the port the best I can, its open for grabs if anyone is interested…
From what it looks to me I have to ask if you remembered to put nsd_enable=“YES” into your /etc/rc.conf file?
The rc.d scripts do not have to end with “.sh”, it affects how they are run, “.sh” scripts are sourced into the current shell rather than a subshell and the startup process will terminate if the script does, non “.sh” scripts on the other hand are not sourced into the current shell and do not stop the startup process if they terminate. As far as I know this also applies to FreeBSD 6.0
/Oli
Being the NSD FreeBSD port maintainer I noticed this thread on the list (although I still didn't receive your report to me directly).
Hrm. It was sent about a minute before this last message to the list.
I have long ago stopped running FreeBSD+NSD setups but have been maintaining the port the best I can, its open for grabs if anyone is interested...
Others on this list? I'm not up to port maintainer skills, I believe.
From what it looks to me I have to ask if you remembered to put nsd_enable="YES" into your /etc/rc.conf file?
Yes, definitely.
The rc.d scripts do not have to end with ".sh", it affects how they are run, ".sh" scripts are sourced into the current shell rather than a subshell and the startup process will terminate if the script does, non ".sh" scripts on the other hand are not sourced into the current shell and do not stop the startup process if they terminate. As far as I know this also applies to FreeBSD 6.0
I can assure you: the two scripts in /usr/local/etc/rc.d that did not end in ".sh" both ran fine when run from the command line by the root user, but didn't even try to be run during startup. As soon as I renamed them with .sh and rebooted, they came up fine.
Paul Hoffman wrote:
Being the NSD FreeBSD port maintainer I noticed this thread on the list (although I still didn't receive your report to me directly).
Hrm. It was sent about a minute before this last message to the list.I have long ago stopped running FreeBSD+NSD setups but have been maintaining the port the best I can, its open for grabs if anyone is interested...
Others on this list? I'm not up to port maintainer skills, I believe.>From what it looks to me I have to ask if you remembered to put nsd_enable="YES" into your /etc/rc.conf file?
Yes, definitely.
The rc.d scripts do not have to end with ".sh", it affects how they are run, ".sh" scripts are sourced into the current shell rather than a subshell and the startup process will terminate if the script does, non ".sh" scripts on the other hand are not sourced into the current shell and do not stop the startup process if they terminate. As far as I know this also applies to FreeBSD 6.0
I can assure you: the two scripts in /usr/local/etc/rc.d that did not end in ".sh" both ran fine when run from the command line by the root user, but didn't even try to be run during startup. As soon as I renamed them with .sh and rebooted, they came up fine.
Just a thought - was the script /usr/local/etc/rc.d/nsd executable? By that I mean the mode on the file is rwxr-xr-x or similar
I think a script file that is not executable would be skipped, unless it ends in .sh (the test is in run_rc_script)
Richard.
Yes, all files in /usr/local/etc/rc.d had the same permissions.
Hi guys,
I've been running on NSD on FreeBSD for a couple of years now, haven't seen that problem. What version of NSD and FreeBSD are you using? Also, the logs would be very helpful.
Paul Hoffman wrote:
Being the NSD FreeBSD port maintainer I noticed this thread on the list
(although I still didn't receive your report to me directly). I have long
ago stopped running FreeBSD+NSD setups but have been maintaining the port
the best I can, its open for grabs if anyone is interested...
If you want, I can take over the port. I already do the openddnssec
port, and am somewhat closer to the nsd source.
>From what it looks to me I have to ask if you remembered to
put nsd_enable="YES" into your /etc/rc.conf file?
The rc.d scripts do not have to end with ".sh", it affects how
they are run, ".sh" scripts are sourced into the current shell
rather than a subshell and the startup process will terminate
if the script does, non ".sh" scripts on the other hand are not
sourced into the current shell and do not stop the startup
process if they terminate. As far as I know this also applies
to FreeBSD 6.0
The rc scripts methods of FreeBSD have been in a state of flux for
a while so this might indeed be part of the problem.
jaap
As I said earlier, FreeBSD 6.0. And as I said earlier, there was nothing at all in the logs. As it turns out, that was because the scripts weren't even being seen.
It would be great if someone from NLnetLabs was the port owner!