Debian 6.0.7 Squeeze bind9 probléma

Debian GNU/Linux

Véletlenszerűen megáll a named működése. Maga a processz fut, néhány százalékos CPU terheltség mellett, de a névfeloldás nem megy. A syslogban a probléma jelentkezése után csak annyi infó keletkezik, hogy
"named: error (network unreachable)" viszont a szerveren lévő egéb alkalmazások, pl.: mrtg, smokeping, snmp, apache2 kommunikálnak a külvilággal, tehát a hálózat jó. Lehetséges, hogy a beállított forwarder szerver nem elérhető, de ezt nem tudtam leellenőrizni. Csinálok egy monitort rá de addig is felteszem a kérdést: Találkozott már valaki ilyennel? Érdekesség még, hogy mielőtt a szervert frissítettem volna Lenny-ről, nem volt ilyen gondom, most pedig ez a második eset.

Update: amikor a hiba jelentkezik, csak percek alatt lehet belépni ssh-val és a /etc/init.d/bind9 script "lefagy" leállításkor, mintha nem tudná leállítani/kilőni a named pidjét. A forwarder szerverrel nem volt gond. Érdekesség még, hogy néha "megjavul" magától.

  • 11411 megtekintés

( Oops | 2013. 03. 11., h – 11:30 )

mekkora a gép load-ja? mekkora a szabad fizikai memória? a percek alatt történő bejelentkezés ebből is származhat.

( rts | 2013. 03. 11., h – 13:36 )

resolv.confba 8.8.8.8, ne localhostot.
akkor se tudsz rálépni?
--
#conf t
#int world
#no shut

a részletes queries logot kéne kapnod, ha mindent bekapcsolsz. szépen tudod szeparálni a logokat. holnap dobok egy configot hogy nekem hogy van.
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/


logging {
channel default_file { file "/var/log/default.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel general_file { file "/var/log/general.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel database_file { file "/var/log/database.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel security_file { file "/var/log/security.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel config_file { file "/var/log/config.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel resolver_file { file "/var/log/resolver.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel xfer-in_file { file "/var/log/xfer-in.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel xfer-out_file { file "/var/log/xfer-out.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel notify_file { file "/var/log/notify.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel client_file { file "/var/log/client.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel unmatched_file { file "/var/log/unmatched.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel queries_file { file "/var/log/queries.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel network_file { file "/var/log/network.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel update_file { file "/var/log/update.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel dispatch_file { file "/var/log/dispatch.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel dnssec_file { file "/var/log/dnssec.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel lame-servers_file { file "/var/log/lame-servers.log" versions 3 size 5m; severity dynamic; print-time yes;};
category default { default_file; };
category general { general_file; };
category database { database_file; };
category security { security_file; };
category config { config_file; };
category resolver { resolver_file; };
category xfer-in { xfer-in_file; };
category xfer-out { xfer-out_file; };
category notify { notify_file; };
category client { client_file; };
category unmatched { unmatched_file; };
category queries { queries_file; };
category network { network_file; };
category update { update_file; };
category dispatch { dispatch_file; };
category dnssec { dnssec_file; };
category lame-servers { lame-servers_file; };
};

--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/

remélem segítettem, és hogy a logokból jutsz valamire, legalább hogy milyen lekérdezések vezetnek a probléma megjelenéséhez.

az update alapján, vlami hasonló volt nekem is RHEL 6.2. ott találkoztam ilyennel, hogy a named nem bírt leállni. upgrade lett a vége.
Milyen kernelt használsz, esetleg a függőségek:

You can finding out what dependencies a rpm file has i.e. it will tell you what you need to install package with following command:
rpm -qpR {.rpm-file}
rpm -qR {package-name}

lehet hogy valahol csuklik a named. Esetleg egy debug futás (severity debug) amikor már tudod hogy mi váltja ki a "fagyást"

--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/

( veyron007 | 2013. 03. 13., sze – 10:17 )

Te vagy a tartományod név kezelője, vagy a szolgáltató?