Bind Process Randomly Shuts Down

[vetch101]

Hi everyone,

I am running a Debian Etch ISPCP Omega RC6 with nothing else installed.

Over the last few weeks, the Bind process seems to randomly shutdown.
Sometimes there are logs about it, saying:-
Feb 16 07:30:14 vps named[9553]: shutting down: flushing changes
Feb 16 07:30:14 vps named[9553]: stopping command channel on 127.0.0.1#953
Feb 16 07:30:14 vps named[9553]: stopping command channel on ::1#953
Feb 16 07:30:14 vps named[9553]: no longer listening on ::#53
Feb 16 07:30:14 vps named[9553]: no longer listening on 127.0.0.1#53
Feb 16 07:30:14 vps named[9553]: no longer listening on IP.ADDRESS.OF.VPS#53
Feb 16 07:30:14 vps named[9553]: no longer listening on IP.ADDRESS.OF.VPS#53
Feb 16 07:30:14 vps named[9553]: exiting

Other times, the process has just disappeared without any messages.
Does anyone know why this might be happening, or what I can do to diagnose and eventually resolve it?
Alternatively, does anyone know why it might happen given that it tends to occur around the hour or the half-hour...

Many thanks,

Jx

---

BTW - how can I add a secondary DNS server to the bind scripts...
Any changes I make seem to be overwritten when I restart the server.

Cheers,

Jx

[BeNe]

Quote:BTW - how can I add a secondary DNS server to the bind scripts...
Any changes I make seem to be overwritten when I restart the server.

May this helps:
http://www.isp-control.net/documentation...nameserver

You can also set a secondary DNS Server in the ispcp.conf (etc/ispcp/ispcp.conf)

Code:

#
# BIND data
#

BIND_CONF_FILE = /etc/bind/named.conf

BIND_DB_DIR = /var/cache/bind

SECONDARY_DNS =

Greez BeNe

[vetch101]

(02-17-2009 07:34 PM)BeNe Wrote:  

Quote:BTW - how can I add a secondary DNS server to the bind scripts...
Any changes I make seem to be overwritten when I restart the server.

May this helps:
http://www.isp-control.net/documentation...nameserver

You can also set a secondary DNS Server in the ispcp.conf (etc/ispcp/ispcp.conf)

Code:

#
# BIND data
#

BIND_CONF_FILE = /etc/bind/named.conf

BIND_DB_DIR = /var/cache/bind

SECONDARY_DNS =

Greez BeNe

Thanks BeNe... That looks like what I need to set the Backup DNS...
I'm guessing the SECONDARY_DNS setting will not automatically allow zone transfers and the like without the coding recommended within the FAQ link you sent...
Any ideas about why it might be crashing?

Cheers,

Jx

[BeNe]

Is your Machine ok ? CPU, RAM, I/O ?
Any entry´s in the syslog ?

Is Bind the only services on the Server with such problems ?

Greez BeNe

[vetch101]

(02-17-2009 08:18 PM)BeNe Wrote:  Is your Machine ok ? CPU, RAM, I/O ?
Any entry´s in the syslog ?

Is Bind the only services on the Server with such problems ?

Greez BeNe

Hi,

Yeah - everything seems fine in terms of capacity...
Server is approx 75% CPU idle generally,
Mem: 393216k total, 128828k used, 264388k free,
IO seems fine...

Syslog doesn't tell me anything...
Sometimes it literally has no messages re:named other than when it started...
Sometimes it just says - bind is shutting down...

Bind seems to be the only one with that problem...

Perhaps I could set a higher logging level?

Jx

[vetch101]

Hi all,

FYI, it appears to have been related to an issue our VPS hosts had with their "networking stack". I'm not sure how that could have randomly killed processes within their containers, but since they have told me that they have resolved it, nothing has gone down...

Many thanks for the help, BeNe...

Cheers,

Jx

[vetch101]

Hi all,

I take it back... It may not have been an issue with the hosting company, as they claim to have resolved their issue, but the problem is remaining.

Also, it isn't just the bind process...

It turns out that of about 70 processes running, about 59 shutdown, leaving just 11 running...

top - 15:10:06 up 39 min, 1 user, load average: 0.00, 0.01, 0.00
Tasks: 12 total, 1 running, 11 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.1%us, 0.1%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 393216k total, 27576k used, 365640k free, 0k buffers
Swap: 0k total, 0k used, 0k free, 0k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 15 0 1948 660 564 S 0 0.2 0:01.92 init
3899 root 16 0 1628 588 472 S 0 0.1 0:00.31 syslogd
4035 mysql 15 0 140m 18m 5232 S 0 4.8 0:01.15 mysqld
5186 root 25 0 1752 572 480 S 0 0.1 0:00.00 inetd
5305 root 15 0 5024 1072 768 S 0 0.3 0:00.00 sshd
5322 root 17 0 2404 772 636 S 0 0.2 0:00.00 xinetd
5403 root 19 0 2204 720 568 S 0 0.2 0:00.00 cron
7569 root 15 0 7708 2320 1892 S 0 0.6 0:00.01 sshd
7857 user 18 0 7708 1624 1184 S 0 0.4 0:00.00 sshd
7858 user 15 0 3292 1844 1204 S 0 0.5 0:00.00 sh
7863 user 15 0 2228 988 780 R 0 0.3 0:00.00 top
32141 bind 24 0 90056 3636 2072 S 0 0.9 0:00.05 named

I then reboot the server and all is well for a while...
... and then it happens again.

I've identified (by looking at the logs) that it happens on the hour, or on the half hour, although it seems that a random length of time can occur between failures - though at the moment, it is around 3 a day!

I've been running top in a putty window, watching the server as it goes along, but strangely, putty silently fails when it goes down, rather than throwing an error about the server closing the connection.

When watching it beforehand, I've noticed that on the hour/half hour, some ispcp- tasks run, as do some "diff" processes (which I figure are part of the ispcp task), and then the putty window disappears.

I log back in, and all the services are dead.

Anyone have any idea?

Cheers,

Jx

[kilburn]

I'm quite sure that there's a problem with ispcp-vrl-traff: when run, it consumes every bit of RAM (how many swap space do you have?), and the kernel randomly kills some tasks to free space for it.

This forum post has a patch that greatly reduces the memory overhead of the ispcp-vrl-traff script, so I think applying it will solve your problem.

[vetch101]

(03-10-2009 03:50 AM)kilburn Wrote:  I'm quite sure that there's a problem with ispcp-vrl-traff: when run, it consumes every bit of RAM (how many swap space do you have?), and the kernel randomly kills some tasks to free space for it.

This forum post has a patch that greatly reduces the memory overhead of the ispcp-vrl-traff script, so I think applying it will solve your problem.

Hi,

I checked with my VPS provider - their logs show that services are being killed with Out Of Memory errors, so this looks like it might be just exactly what I need! Many thanks!

I'll give it a try and come back with info on how it worked...

Cheers,

Jx