[Napster]

laughing out loud.....

vor einem Jahr hatte ich die NIC eine Via Rhine-II VT6102 im 100m/bit Rootserver öffentlich bemängelt und OVH gebettelt sie mögen doch mal die Nic tauschen.....
Keine Reaktion von OVH das es wirklich daran liegen könnte, geschweige das ein Tausch stattfand. Hab mich bestimmt 3 Monate mit dem Scheiss beschäftigt, dann gekündigt.

Ein Jahr später verbaut OVH eine andere NIC in die 100m/bit Rootserver undzwar eine: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit
Ethernet controller
und alles funktioniert ohne jegliche oben beschriebener Symtome.....das doch nen Witz oda

...laughing out loud

mfg

[Napster]

Servus,
Da bin ich mal wieder und wollt das mal aktualisieren, da ich ja denke das der eine oder andere betroffene das hier auch mit verfolgt.
der server ist jetzt uptime: up 3 days, 8:42
mit genau der selben konfiguration wie mit der er nach 10h stunden off ging.
Habe inzwischen auch einige meldungen in den logs bekommen:

/log/messages

Aug 22 14:28:55 ovh kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 22 14:28:55 ovh kernel: eth0: Transmit timed out, status 0003, PHY status 786d, resetting...
Aug 22 14:28:55 ovh kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x41E1

Aug 22 20:14:07 ovh kernel: eth0: Too much work at interrupt, status=0x00000002.
Aug 22 20:15:03 ovh kernel: eth0: Too much work at interrupt, status=0x00000001.

Aug 23 03:04:45 ovh kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 23 03:04:45 ovh kernel: eth0: Transmit timed out, status 1003, PHY status 786d, resetting...
Aug 23 03:04:45 ovh kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x41E1

Aug 23 11:31:10 ovh kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 23 11:31:10 ovh kernel: eth0: Transmit timed out, status 0003, PHY status 786d, resetting...
Aug 23 11:31:10 ovh kernel: via-rhine: Reset not complete yet. Trying harder.
Aug 23 11:31:10 ovh kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x41E1

Aug 23 19:56:13 ovh kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 23 19:56:13 ovh kernel: eth0: Transmit timed out, status 0003, PHY status 786d, resetting...
Aug 23 19:56:13 ovh kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x41E1

Aug 23 20:57:51 ovh kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 23 20:57:51 ovh kernel: eth0: Transmit timed out, status 0003, PHY status 786d, resetting...
Aug 23 20:57:51 ovh kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x41E1

seitdem ruhe im moment, wie gesagt, nix ge/verändert

sowie in der /log/auth.log:

Aug 22 19:23:46 ovh sshd[4768]: Disconnecting: Corrupted MAC on input.

Habe mal gegoogelt und viele seiten mit ähnlichen inhalt gefunden wie folgt:

Im Prinzip ist das nur eine Überlastwarnung und ein Schutzmechanismus, damit der Treiber nicht den
Rechner komplett lahmlegt, wenn die Karte ausgelastet ist...
Deine Netzwerkkarte hat sich entweder einen Interrupt eingefangen bevor sie mit dem letzten fertig war,
oder ein im Treiber eingebauter Schwellwert für die Dauer im Interrupt wurde überschritten... Die Ursache
kann entweder buggy Hardware sein, billige Hardware (Karte produziert zu viele Interrupts) oder ein lahmer
Treiber.

Es ist eine Via Rhine-II VT6102 verbaut, diese Netzwerkkarten sollen billigschrott sein, bzw. auch die treiber für diese karten.
mfg

[sledge0303]

kernel: IPv6 addrconf: prefix with wrong length 56

Nur nervig der Eintrag, sonst harmlos. Kannst beheben, indem du IPV6 deaktivierst. Hat also mit dem Problem nichts zu tun. Schick mal eine Mail an den Kundendienst, die sollen sich den Server/Installation mal genauer ansehen.
Von der Ferne kann ich selbst auch nicht viel ausrichten, müsste dazu noch mehr Informationen erhalten.

ach ja sledge: Ich habe noch keinen reboot gemacht ,aber debian hat nen neues etch-kernel-image rausgebracht: 2.6.18-5-686
ggf. kannste uns ja mal beruhigen ,welche konsequenzen das update auf die etch-from-scratch-install hat muss ich am grub nochwas umstellen? sieht fast so aus, da die menu.lst nochauf der 4er Version ist.

Konsequenz: einen neuen Kernel nach der Installation
Die menu.lst aktualisiert sich nach Installation des Image eigentlich selbst, kannst zur Sicherheit 'update-grub' in die Tasten hauen und anschließend reboot.

[Napster]

@snoopotic,
danke, aber die resolv.conf ist nicht leer.

Übrigens ich hatte nach 10h uptime wieder das Problem. Ping ja, ssh bzw. webmin nein. Hatte daraufhin nen reboot im (aussversehen) rescue modus gemacht und auch NIE ein pass erhalten. Da man erst nach ner halben stunde wieder nen reboot machen kann, verstehe zwar um vielleicht Missbrauch zu vermeiden, aber da geht einem Zeit flöten ohne Ende, hatte ich einen normalen reboot auf hdd gemacht. Der Server ist seitdem up: 17:45:45 up
Ich kann mir das nicht erklären, das ein Server nen paar Stunden oder/und nen paar Tage hält und dann mir nix dir nix abkaggt, bzw. ssh.
das einzigste was die syslog als fehler rausgibt ist:
kernel: IPv6 addrconf: prefix with wrong length 56

[Snoopotic]

ähm. Das hat jetzt bestimmt nur wenig mit deinem Problem zu tun, aber ptüpfe auch mal, dass deine /etc/resolv.conf NICHT leer ist. Wenn doch, fülle sie und deinstalliere resolvconf (apt-get --purge remove resolvconf) Irgendwie muss ich mir das mal installiert haben und hatte auch nach etwa 5 Tagen die Probleme, die Kiste zu erreichen. bzw mit der kiste irgendwelche domains...

ach ja sledge: Ich habe noch keinen reboot gemacht ,aber debian hat nen neues etch-kernel-image rausgebracht: 2.6.18-5-686
ggf. kannste uns ja mal beruhigen ,welche konsequenzen das update auf die etch-from-scratch-install hat muss ich am grub nochwas umstellen? sieht fast so aus, da die menu.lst nochauf der 4er Version ist.

[sledge0303]

Hast mal die Werte aus 'top' und 'free' regelmäßig überprüft? Evtl. nimmt ein Dienst mehr Speicher in Anspruch als er eigentlich sollte!?
Ansonsten auch mal die Cronjobs diesbezüglich prüfen.

[Napster]

hmmm, eigentlich werden die älteren Logs nach einem Reboot des Servers/Dienste weder gelöscht noch überschrieben, sondern als syslog.0, syslog.1 abgelegt in /var/log

stimmt, dort ist aber absolut nix auffälliges zu finden,
was dort steht kann ich auch hier posten, das wiederholt sich dann immer wieder, hatte vnstat installiert:

Aug 12 07:17:01 ovh /USR/SBIN/CRON[13805]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 12 07:20:01 ovh /USR/SBIN/CRON[13808]: (root) CMD (if [ -x /usr/bin/vnstat ] && [ `ls /var/lib/vnstat/ | wc -l` -ge 1 ]; then /usr/bin/vnstat -u; fi)
Aug 12 07:25:01 ovh /USR/SBIN/CRON[13815]: (root) CMD (if [ -x /usr/bin/vnstat ] && [ `ls /var/lib/vnstat/ | wc -l` -ge 1 ]; then /usr/bin/vnstat -u; fi)
Aug 12 07:30:01 ovh /USR/SBIN/CRON[13821]: (root) CMD (if [ -x /usr/bin/vnstat ] && [ `ls /var/lib/vnstat/ | wc -l` -ge 1 ]; then /usr/bin/vnstat -u; fi)
Aug 12 07:35:01 ovh /USR/SBIN/CRON[13827]: (root) CMD (if [ -x /usr/bin/vnstat ] && [ `ls /var/lib/vnstat/ | wc -l` -ge 1 ]; then /usr/bin/vnstat -u; fi)
Aug 12 07:40:01 ovh /USR/SBIN/CRON[13833]: (root) CMD (if [ -x /usr/bin/vnstat ] && [ `ls /var/lib/vnstat/ | wc -l` -ge 1 ]; then /usr/bin/vnstat -u; fi)
Aug 12 07:45:01 ovh /USR/SBIN/CRON[13839]: (root) CMD (if [ -x /usr/bin/vnstat ] && [ `ls /var/lib/vnstat/ | wc -l` -ge 1 ]; then /usr/bin/vnstat -u; fi)
Aug 12 07:50:01 ovh /USR/SBIN/CRON[13845]: (root) CMD (if [ -x /usr/bin/vnstat ] && [ `ls /var/lib/vnstat/ | wc -l` -ge 1 ]; then /usr/bin/vnstat -u; fi)
Aug 12 07:55:01 ovh /USR/SBIN/CRON[13852]: (root) CMD (if [ -x /usr/bin/vnstat ] && [ `ls /var/lib/vnstat/ | wc -l` -ge 1 ]; then /usr/bin/vnstat -u; fi)
Aug 12 08:00:01 ovh /USR/SBIN/CRON[13858]: (root) CMD (if [ -x /usr/bin/vnstat ] && [ `ls /var/lib/vnstat/ | wc -l` -ge 1 ]; then /usr/bin/vnstat -u; fi)
Aug 12 08:05:01 ovh /USR/SBIN/CRON[13864]: (root) CMD (if [ -x /usr/bin/vnstat ] && [ `ls /var/lib/vnstat/ | wc -l` -ge 1 ]; then /usr/bin/vnstat -u; fi)
Aug 12 08:10:01 ovh /USR/SBIN/CRON[13870]: (root) CMD (if [ -x /usr/bin/vnstat ] && [ `ls /var/lib/vnstat/ | wc -l` -ge 1 ]; then /usr/bin/vnstat -u; fi)
Aug 12 08:15:01 ovh /USR/SBIN/CRON[13876]: (root) CMD (if [ -x /usr/bin/vnstat ] && [ `ls /var/lib/vnstat/ | wc -l` -ge 1 ]; then /usr/bin/vnstat -u; fi)
Aug 12 08:17:01 ovh /USR/SBIN/CRON[13882]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)

was ich weis ist, ssh beendet sich nicht selbst, das würde dann so aussehen:

[SSH] FAIL: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte.

sondern die fehlermeldung sagt doch lediglich folgendes aus:
der sshd nimmt die Connection entgegen, stellt fest, daß
Du nicht darfst, und macht die Connection wieder zu.
....aber warum? und warum geht dann mit webmin ausserdem auch nix mehr?
mfg

[sledge0303]

Hi,
die syslog ist mit dem heutigen restart überschrieben worden, bringt demzufolge nicht viel. müsste dann wohl in 7 tagen den server im rescue restarten lassen und dann nachgucken?

hmmm, eigentlich werden die älteren Logs nach einem Reboot des Servers/Dienste weder gelöscht noch überschrieben, sondern als syslog.0, syslog.1 abgelegt in /var/log

... oder bügelst die Dinger immer weg?

[Napster]

Hi,
die syslog ist mit dem heutigen restart überschrieben worden, bringt demzufolge nicht viel. müsste dann wohl in 7 tagen den server im rescue restarten lassen und dann nachgucken?

p.s. doch man (ich) möchte root das login erlauben

mfg

[sledge0303]

Hallo,

schau mal in die Syslogs rein, sofern noch vorhanden. Wenn der Aufall periodisch auftritt, d.h. du könntest danach fast die Uhr nach stellen, könnte ein Dienst amok laufen. Du kannst mir diese Logs, wenn es nicht deuten kannst was die Einträge bedeuten, per Mail zusenden.

sledge0303_AT_hotmail_DOT_com

Achja, wenn ich mir deine SSH Config anschaue. Auch wenn im Howto darauf nicht genauer eingegangen wird, man möchte root nicht das Login erlauben und dem User nur per Key auf die Konsole lassen.

[Napster]

Hi,
Folgende Eckdaten:
Dedizierter Server Superplan2007L
Etch 'from scratch' nach dem Howto von Sledge0303 installiert
Webmin installiert
in der hosts.allow: sshd: ALL : ALLOW

Das Problem:
Nach etwa 5-7 Tagen sind keine Dienste mehr verfügbar, weder ssh noch webmin oder sonstwas und das obwohl der server weiterhin pingbar ist.

ssh error: [SSH] ssh_exchange_identification: Connection closed by remote host
Mit Webmin kommt man dann auch nicht mehr rauf.

Beantragt man nun einen hart-reboot, läuft wieder alles einwandfrei und ohne Probleme. Das ganze wieder etwa 5-7 Tage. Dieses Phänomen ist mir nur bei OVH bekannt. Bei anderen Hostern kommt so etwas wohl auch schon mal vor, aber dann kann man den Server auch nicht mehr anpingen und ist demzufolge vom Netz.
Vielleicht hat der eine oder andere auch dieses Problem bzw. eine Lösung?

P.S. ssh wurde schon mal neu installiert, die ssh keys wurden auch neu generiert.
Meine sshd_conf:
# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication yes


# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd yes
PrintLastLog yes
KeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

Subsystem sftp /usr/lib/sftp-server

IgnoreUserKnownHosts no

UsePrivilegedPort no

mfg