| Posted by RandomThoughts, 11-30-2009, 07:40 AM | | For the past few days I've had problems with Named shutting down for seemingly no reason. It's running on a Plesk server & recently I updated Named via the CP.
service named status shows
rndc: connect failed: 127.0.0.1#953: connection refused
named dead but subsys locked
/var/log/messages shows
Nov 28 00:02:01 betelgeuse named[5365]: shutting down
Nov 28 00:02:01 betelgeuse named[5365]: stopping command channel on 127.0.0.1#953
Nov 28 00:02:01 betelgeuse named[5365]: no longer listening on 127.0.0.1#53
Nov 28 00:02:01 betelgeuse named[5365]: no longer listening on ***.***.***.***#53
Nov 28 00:02:01 betelgeuse named[5365]: no longer listening on ***.***.***.***#53
Nov 28 00:02:01 betelgeuse named[5365]: no longer listening on ***.***.***.***#53
Nov 28 00:02:01 betelgeuse named[5365]: no longer listening on ***.***.***.***#53
Nov 28 00:02:01 betelgeuse named[5365]: exiting
Named starts without any issues when I've spotted the problem, anyone any clues?
|
| Posted by inspiron, 11-30-2009, 07:58 AM | | I guess it might be permission problem. Just make once sure that permissions are set,
chmod 755 /var/run/named
chmod 750 /var/named
and then starting again.
|
| Posted by ksv2nash, 11-30-2009, 08:20 AM | | Hi,
just check named status
service named status
if there is dead process then delete it
then restart named
|
| Posted by RandomThoughts, 11-30-2009, 08:43 AM | | I'd rather it didn't shut down at all, I can find no reason for it
|
| Posted by ksv2nash, 11-30-2009, 08:45 AM | | Hello,
if named.conf is corrupt or needs rebuilding you can:
Method 1
cd /scripts;
service named stop ; killall -9 named ; mv /etc/named.conf /etc/named.old ; ./rebuildnamedconf > /etc/named.conf ; ./fixndc ; ./fixndc
ndc status
|
| Posted by RandomThoughts, 12-15-2009, 09:38 AM | | After a pause of a few weeks, it's doing it again. I see in all the bumph when I check the service status a listing for debug level, what do you think I should set that to to find the problem without filling the logs too quick?
|
| Posted by sightlesss, 01-11-2010, 07:36 AM | | Hi,
I have been experiencing the same thing with BIND 9.5.1-P3 on Debian 5 (lenny). I found an *old* thread the mentioned logrotate:
https://lists.isc.org/pipermail/bind...ry/022244.html
and noticed that for me the problem may well be related to log files somehow. I can reliably kill the server by simply editing syslog, i.e. I can do
/etc/init.d/bind9 start
ps xa | grep named
# server is definitely running
vim /var/log/syslog
# quit vim immediatly with :q
ps xa | grep named
# server is no longer running
I can do this absolutely reliably.
When it shuts down this way, it shows messages like this in syslog:
Jan 11 22:21:37 noema named[25917]: shutting down
Jan 11 22:21:37 noema named[25917]: stopping command channel on 127.0.0.1#953
Jan 11 22:21:37 noema named[25917]: stopping command channel on ::1#953
Jan 11 22:21:37 noema named[25917]: no longer listening on ::#53
Jan 11 22:21:37 noema named[25917]: no longer listening on 127.0.0.1#53
Jan 11 22:21:37 noema named[25917]: no longer listening on #53
Jan 11 22:21:37 noema named[25917]: exiting
When it shuts down properly (e.g. by reboot or /etc/init.d/bind9 stop) I see things more like this:
Jan 11 00:01:18 noema named[26422]: received control channel command 'stop -p'
Jan 11 00:01:18 noema named[26422]: shutting down: flushing changes
Jan 11 00:01:18 noema named[26422]: stopping command channel on 127.0.0.1#953
Jan 11 00:01:18 noema named[26422]: stopping command channel on ::1#953
Jan 11 00:01:18 noema named[26422]: no longer listening on ::#53
Jan 11 00:01:18 noema named[26422]: no longer listening on 127.0.0.1#53
Jan 11 00:01:18 noema named[26422]: no longer listening on #53
Jan 11 00:01:18 noema named[26422]: exiting
I don't yet have a solution, but I guess this is a step closer...I will be reviewing the log options of named!
I also see the following warning as named starts, which I don't think is relevant, but mentioning just in case:
Jan 10 23:51:09 noema named[26422]: max open files (1024) is smaller than max sockets (4096)
Jan 10 23:51:09 noema named[26422]: using default UDP/IPv4 port range: [1024, 65535]
Jan 10 23:51:09 noema named[26422]: using default UDP/IPv6 port range: [1024, 65535]
Everything else seems in order.
Any ideas appreciated. I'll post again if/when I make more progress.
Ben.
|
| Posted by LeaTrueman, 01-11-2010, 07:59 AM | | Hello,
Please try to add the following line in rndc.conf and restart named,
include "/etc/rndc.key";
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
};
|
| Posted by sightlesss, 01-11-2010, 07:59 AM | | Perhaps a false alarm...named seemed to die for heaps of other reasons, too. Rebooting the VPS seemed to fix things up. Still not sure what's going on. Maybe out of memory problems if this thread is anything to go by:
http: //isp-control.net/forum/thread-5743.html
Still would appreciate any insight anyone can give!
Ben.
|
| Posted by sightlesss, 01-11-2010, 08:37 PM | | Thanks for the input. I don't use rndc and don't have an rndc.conf file, and there is no controls block in my named.conf so rndc and keys and so on shouldn't be relevant.
I investigated the out-of-memory possibility more thoroughly, and indeed the VPS was experiencing out of memory problems at the times when named was dying. Since it's a VPS, processes are just killed off when memory is exhausted rather than swap space being used. Without cross-referencing logs it's hard to see why they're dying. In this case named was reliably the victim, but I suppose it could've been any process. Tweaking apache's settings so it doesn't spawn processes until RAM is exhausted should make things happier. And setting up a cron job or something to notice when processes do die and restart them. Then as long as cron doesn't get killed... It's hard to make this failsafe when you can't rely on any process really staying there... I suppose I need something in inittab which is respawned rather than just started with /etc/init.d/whatever, so it will stick around or be restarted despite what might get killed--some kind of supervisor process that checks processes which should be running and restarts them using /etc/init.d scripts when they die, preferably after waiting for memory usage to reach a suitable level first--or in the short term, perhaps just cron which I can set up suitably!
Ben.
|
| Posted by foobic, 01-11-2010, 09:21 PM | | Take a look at SIM, if you haven't already. Obviously though, you also need to find out why it's running out of memory and fix the root problem.
|
| Posted by LeaTrueman, 01-12-2010, 01:28 AM | | Hello,
Could you please check whether max-cache-size variable has been set in your named.conf. If it is not set, then it will be unlimited by default. Please check it.
|
|
 Add to Favourites
 Print this Article
|
