named macht probleme -> webserver nicht erreichbar

L

loki_sft

Registered User
hallo
ich habe ein grösseres problem mit meinem vserver
(debian sarge bei winprofi.de mit syscp)
etwa jede stunden macht der ganze server einfach dicht, er akzeptiert weder ftp noch http, aber "anpingbar" ist er noch.
in der daemon.log steht folgendes:
Code: 
Mar 20 04:37:23 vs-241-72 named[27511]: listening on IPv4 interface eth0:vs-241-72, 213.131.241.72#53
Mar 20 04:37:24 vs-241-72 named[27511]: could not listen on UDP socket: permission denied
Mar 20 04:37:24 vs-241-72 named[27511]: creating IPv4 interface eth0:vs-241-72 failed; interface ignored
Mar 20 04:37:24 vs-241-72 named[27511]: not listening on any interfaces
Mar 20 04:40:57 vs-241-72 named[1990]: listening on IPv4 interface eth0:vs-241-72, 213.131.241.72#53
Mar 20 04:40:57 vs-241-72 named[1990]: could not listen on UDP socket: permission denied
Mar 20 04:40:57 vs-241-72 named[1990]: creating IPv4 interface eth0:vs-241-72 failed; interface ignored
Mar 20 04:40:57 vs-241-72 named[1990]: not listening on any interfaces
Mar 20 05:37:24 vs-241-72 named[27512]: listening on IPv4 interface eth0:vs-241-72, 213.131.241.72#53
Mar 20 05:37:24 vs-241-72 named[27512]: could not listen on UDP socket: permission denied
Mar 20 05:37:24 vs-241-72 named[27512]: creating IPv4 interface eth0:vs-241-72 failed; interface ignored
Mar 20 05:37:24 vs-241-72 named[27512]: not listening on any interfaces
Mar 20 05:40:57 vs-241-72 named[1988]: listening on IPv4 interface eth0:vs-241-72, 213.131.241.72#53
Mar 20 05:40:57 vs-241-72 named[1988]: could not listen on UDP socket: permission denied
Mar 20 05:40:57 vs-241-72 named[1988]: creating IPv4 interface eth0:vs-241-72 failed; interface ignored
Mar 20 05:40:57 vs-241-72 named[1988]: not listening on any interfaces
Mar 20 06:37:24 vs-241-72 named[27511]: listening on IPv4 interface eth0:vs-241-72, 213.131.241.72#53
Mar 20 06:37:24 vs-241-72 named[27511]: could not listen on UDP socket: permission denied
Mar 20 06:37:24 vs-241-72 named[27511]: creating IPv4 interface eth0:vs-241-72 failed; interface ignored
Mar 20 06:37:24 vs-241-72 named[27511]: not listening on any interfaces
Mar 20 06:40:57 vs-241-72 named[1990]: listening on IPv4 interface eth0:vs-241-72, 213.131.241.72#53
Mar 20 06:40:57 vs-241-72 named[1990]: could not listen on UDP socket: permission denied
Mar 20 06:40:57 vs-241-72 named[1990]: creating IPv4 interface eth0:vs-241-72 failed; interface ignored
Mar 20 06:40:57 vs-241-72 named[1990]: not listening on any interfaces
Mar 20 07:37:24 vs-241-72 named[27512]: listening on IPv4 interface eth0:vs-241-72, 213.131.241.72#53
Mar 20 07:37:24 vs-241-72 named[27512]: could not listen on UDP socket: permission denied
Mar 20 07:37:24 vs-241-72 named[27512]: creating IPv4 interface eth0:vs-241-72 failed; interface ignored
Mar 20 07:37:24 vs-241-72 named[27512]: not listening on any interfaces
Mar 20 07:40:57 vs-241-72 named[1988]: listening on IPv4 interface eth0:vs-241-72, 213.131.241.72#53
Mar 20 07:40:57 vs-241-72 named[1988]: could not listen on UDP socket: permission denied
Mar 20 07:40:57 vs-241-72 named[1988]: creating IPv4 interface eth0:vs-241-72 failed; interface ignored
Mar 20 07:40:57 vs-241-72 named[1988]: not listening on any interfaces

und immer so weiter
ich dachte mir, das da ein cron verrückt spielt, aber ich kann nichts finden
cron.hourly ist leer und in cron.d steht:
php4 -rwxr-xr-x root
postgresql -rwxr-xr-x root
syscp -rw-r--r-- root

inhalt php4:
Code: 
# /etc/cron.d/php4: crontab fragment for php4
#  This purges session files older than X, where X is defined in seconds
#  as the largest value of session.gc_maxlifetime from all your php.ini
#  files, or 24 minutes if not defined.  See /usr/lib/php4/maxlifetime

# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -d /var/lib/php4 ] && find /var/lib/php4/ -type f -cmin +$(/usr/lib/php4/maxlifetime) -print0 | xargs -r -0 rm

inhalt postgresql:

Code: 
# Regular cron jobs for the postgresql package
#
# To ensure proper access rights, 'ident sameuser' access for localhost is
# required in /etc/postgresql/pg_hba.conf.  This is now the default setting for
# the Debian configuration.
#
# If password access for "local" is turned on in /etc/postgresql/pg_hba.conf,
# you must create a file ~postgres/.pgpass containing a line specifying the
# password, as explained in section 1.11 of the PostgreSQL Programmer's Guide
# (package postgresql-doc).
#
# If autovacuum is turned on in /etc/postgresql/postmaster.conf, you need
# to give the -F option to do.maintenance for it to do anything.

# Run VACUUM ANALYSE on all databases every 5 hours
2 0,5,10,15,20 * * 1-6 postgres   if [ -z "`ps --no-headers -C pg_autovacuum`" -a -x /usr/lib/postgresql/bin/do.maintenance ]; then /usr/lib/postgresql/bin/do.maintenance -a; fi

# On Sunday run a VACUUM FULL ANALYSE as well
# If you run a 24/7 site, you may want to comment out this line and save VACUUM
# FULL for when you think you really need it
# 10 3 * * sun postgres   /usr/bin/test -x /usr/lib/postgresql/bin/do.maintenance && /usr/lib/postgresql/bin/do.maintenance -a -f -F

inhalt syscp:
Code: 
#
# Set PATH, otherwise restart-scripts won't find start-stop-daemon
#
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
#
# Regular cron jobs for the syscp package
#
*/5 * * * *   root   /usr/bin/php4 -q -c /etc/php4/syscpcron /var/www/syscp/scripts/cronscript.php

/var/spool/cron ist leer

ich weiss nicht mehr weiter...
 
Ansatz:
Sieht so aus als würde der Befehl /etc/init.d/network restart bzw stop oder soetwas in der Art durchgeführt, wenn sogar der Host nicht pingbar ist. Wie siehts mit der Uptime denn aus? Kommt die Erreichbarkeit wieder von selbst zurrück?
 
Hallo!
Sieht so aus, als wenn dein Nameserver nicht so richtig will. Probier bitte mal:
Code: 
/etc/init.d/named stop
ps -aux|grep named
Nach dem stop Befehl sollten keine named Prozesse mehr laufen. Falls doch, mit
Code: 
killall named
beenden. Beim nächsten Startversuch von named mittels
Code: 
/etc/init.d/named start
solltest du angezeigt bekommen wo das Problem liegt. Eventuell kann das pid file nicht geschrieben werden.

mfG
Thorsten
 
also neustarten tut der server nicht, die uptime ist bei über 65 tagen

aber mit dem named hab ich irgendwie probleme.
unter init.d gibt es überhaupt keine batch für named !
ps -aux mit grep named bringt nur:
Code: 
bind      1986  0.0  0.0 13248  796 ?        Ss   Feb15   0:00 /usr/sbin/named -u bind
bind      1987  0.0  0.0 13248  796 ?        S    Feb15   0:55 /usr/sbin/named -u bind
bind      1988  0.0  0.0 13248  796 ?        S    Feb15   0:05 /usr/sbin/named -u bind
bind      1990  0.0  0.0 13248  796 ?        S    Feb15   0:05 /usr/sbin/named -u bind
bind      1991  0.0  0.0 13248  796 ?        S    Feb15   0:13 /usr/sbin/named -u bind
bind      1992  0.0  0.0 13248  796 ?        S    Feb15   0:00 /usr/sbin/named -u bind
bind     27509  0.0  0.0 14272 1400 ?        Ss   Mar13   0:00 /usr/sbin/named -u bind
bind     27510  0.0  0.0 14272 1400 ?        S    Mar13   0:22 /usr/sbin/named -u bind
bind     27511  0.0  0.0 14272 1400 ?        S    Mar13   0:02 /usr/sbin/named -u bind
bind     27512  0.0  0.0 14272 1400 ?        S    Mar13   0:02 /usr/sbin/named -u bind
bind     27513  0.0  0.0 14272 1400 ?        S    Mar13   0:05 /usr/sbin/named -u bind
bind     27514  0.0  0.0 14272 1400 ?        S    Mar13   0:00 /usr/sbin/named -u bind

da is doch was faul...
 
Hallo!
Ne, da ist nichts faul. Das ist Debian :)
Versuch mal /etc/init.d/bind_none stop

mfG
Thorsten
 
soooo, jetzt kommen wir der sache schon näher :cool:

bind_none gabs nich, aber bind9 ( hab ich ja auch installiert... *mirselbstamkopfkratz*)

ABER ein bind9 restart bringt:
Code: 
vs-241-72:/# etc/init.d/bind9 restart
Stopping domain name service: namedrndc: connect failed: connection refused
.
Starting domain name service: named.

jetzt weiss ich also, das ein gewisser rndc macken macht.
aber was fange ich jetzt mit diesem wissen an?
 
Hallo!
Nochmal killall named & /etc/init.d/bind9 start
Sollte dann ohne Fehlermeldungen starten.

Du hast ja vorher einen restart versucht. Da musste eine Fehlermeldung kommen - bind lief schließlich nicht.
mfG
Thorsten
 
will immernoch nicht...
er meckert:

vs-241-72:/# etc/init.d/bind9 start
Starting domain name service: namednamed: capset failed: Operation not permitted
named: capset failed: Operation not permitted


ich hab hier im forum gelesen, dass man einen neuen Kernel installieren soll und dabei "capacity" im Kernel aktivieren.

aber davon hab ich nun überhaupt keine schimmer :(
 
Wir auch technisch bei dir möglich sein. Bei einem Vserver kann man den Kernel nicht neu kompilieren
 
Das Problem mit dem rndckey habe ich momentan auch, auf einer Kiste im LAN.
Den named manuell töten und per initscript wieder starten hilft aber.
Bin der Sache mit dem key auf der Spur, das Ding kann nicht vernünftig beendet werden (der Befehl der ausgeführt wird ist "rndc stop", der key dient zur Authentifizierung).

Sobald ich was hab melde ich mich.

<edit>
Komisch, jetzt ging alles...
Code: 
rndc status
und
Code: 
rndc stop
haben klaglos funktioniert...
Merkwürdig.
Naja, auf jeden Fall funkt es hier zumindest wieder.
</edit>

Cheers

tcs
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top