verwandte Themen
Mein Problem ist ähnlich, aber nicht genau dasselbe wieSSH-Pipe unterbrochen, Nachrichtenauthentifizierungscode falschworauf es keine Antwort gibt.
Aufgabe
Kopieren Sie große Dateien von einem Linux auf ein anderes. Beide befinden sich am selben ISP-Standort.
Aufstellen
Quelle und Ziel sind beide: Ubuntu 16.04.3 LTS
SSH-Version auf beiden: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1. März 2016
Die Quellmaschine ist seit einem Jahr im Einsatz, keine Probleme. Die Zielmaschine ist ein frisch eingerichteter dedizierter Server (1 Tag).
scp-Befehl:
scp -P [customport] /some/large/file user@targetmachine:/target/folder/
Die Datei ist ca. 20 GB groß.
Problembeschreibung
Normalerweise bricht es nach etwa 3-4 % ab. Die volle Geschwindigkeit liegt bei etwa 112 MB/s. Wenn ich z. B. mit scp -l 16384 drossele, liegt es bei etwa 2 MB/s, bricht viel später ab, aber bei einem ähnlichen Prozentsatz.
Der Abbruch erfolgt immer auf die gleiche Art und Weise. Der Client erhält:
Write failed: Broken pipe
lost connection
Während der Server dies in /var/log/auth.log hat
Nov 24 13:04:54 Ubuntu-1604-xenial-64-minimal-no-hwe sshd[1900]: Corrupted MAC on input.
Nov 24 13:04:54 Ubuntu-1604-xenial-64-minimal-no-hwe sshd[1900]: fatal: ssh_dispatch_run_fatal: Connection from [client-ip] port 54050: message authentication code incorrect
Untersuchung
Ich habe beides mit aktivierten und deaktivierten iptables versucht, keine Änderung.
Von ca. 10 Versuchen hat es 1 Mal bis zum Ende geklappt, dann kam es bei der nächsten Datei wieder zum Abbruch.
Es scheint, dass nach dem Neustart der Zielmaschine mehr Bytes darauf geschrieben werden können.
SSH ist kein Problem. Ich kann eine inaktive SSH-Verbindung stundenlang offen halten oder eine, bei der der topBefehl ausgeführt wird, ohne dass sie unterbrochen wird.
Fragen
Das ist ein Hindernis. Erstens scheint es unmöglich, eine 200 GB große Datei zu kopieren. Zweitens möchte ich keine Maschine in der Produktion mit Netzwerkproblemen haben.
Was kann ich tun, um dies weiter zu untersuchen?
Ich habe woanders gelesen, dass es sich möglicherweise um ein Problem mit der Netzwerkkarte/Hardware handelt. Wie kann ich dies meinem Anbieter nachweisen, um Ersatz zu erhalten?
Aktualisierung 1
Das Ergebnis für 10 Minuten mtrsieht gut aus:
└─(~)─(49 files, 12Gb)─> mtr -r -c 600 -rw [targetserver]
Start: Fri Nov 24 18:36:21 2017
HOST: Ubuntu-1404-trusty-64-minimal Loss% Snt Last Avg Best Wrst StDev
1.|-- static.XX.XX.XX.XX.clients.your-server.de 0.0% 600 0.5 0.3 0.2 24.5 1.3
2.|-- core24.fsn1.hetzner.com 0.0% 600 0.3 0.3 0.2 6.8 0.4
3.|-- core22.fsn1.hetzner.com 0.0% 600 0.4 0.4 0.3 9.7 0.8
4.|-- ex9k2.dc1.fsn1.hetzner.com 0.0% 600 0.4 0.5 0.3 6.8 0.8
5.|-- my.target.hostname 0.0% 600 0.4 0.3 0.3 0.4 0.0
┌(myuser@Ubuntu-1404-trusty-64-minimal)─(✓)─(06:46 PM Fri Nov 24)
Gleich danach habe ich einen weiteren SCP ausprobiert, der bei 44 % nach 7,5 GB fehlschlug, die Rate lag bei 111 MB/s. Der Fehler trat erneut sofort auf, vorher gab es keine Verzögerungen.
Bezüglich des möglichen Duplikats: Ich habe immer die Meldung „Broken Pipe“ erhalten, nie „Falscher Protokolltyp für Socket“. Ich verwende keinen Mac, beide Linux-Versionen (höher). Ich verwende kein rsync. Die Antwort dort war, dass der Benutzer eine andere Netzwerkkarte in den Server gesteckt hat, ohne herauszufinden, was die eigentliche Ursache war, soweit ich weiß. Ich habe diese Option nicht (dedizierter Server im Remote-Host-Center).
Hier ist die Ausgabe von lshw bezüglich der Netzwerkkarte:
myuser@Ubuntu-1604-xenial-64-minimal-no-hwe /home/myuser # lshw -class network
*-network:0 DISABLED
description: Ethernet interface
product: NetXtreme II BCM57810 10 Gigabit Ethernet
vendor: Broadcom Corporation
physical id: 0
bus info: pci@0000:61:00.0
logical name: eth0
version: 10
serial: e0:d5:5e:1e:73:18
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm vpd msix pciexpress bus_master cap_list rom ethernet physical fibre 1000bt-fd
configuration: autonegotiation=off broadcast=yes driver=bnx2x driverversion=1.712.30-0 firmware=bc 7.14.2 latency=0 link=no multicast=yes port=fibre
resources: iomemory:14c0-14bf iomemory:14c0-14bf iomemory:14c0-14bf irq:81 memory:14c0b000000-14c0b7fffff memory:14c0a800000-14c0affffff memory:14c0b810000-14c0b81ffff memory:e5f80000-e5ffffff memory:14c0ba20000-14c0bc1ffff memory:14c0bca0000-14c0bd1ffff
*-network:1 DISABLED
description: Ethernet interface
product: NetXtreme II BCM57810 10 Gigabit Ethernet
vendor: Broadcom Corporation
physical id: 0.1
bus info: pci@0000:61:00.1
logical name: eth1
version: 10
serial: e0:d5:5e:1e:73:1a
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm vpd msix pciexpress bus_master cap_list rom ethernet physical fibre 1000bt-fd
configuration: autonegotiation=off broadcast=yes driver=bnx2x driverversion=1.712.30-0 firmware=bc 7.14.2 latency=0 link=no multicast=yes port=fibre
resources: iomemory:14c0-14bf iomemory:14c0-14bf iomemory:14c0-14bf irq:102 memory:14c0a000000-14c0a7fffff memory:14c09800000-14c09ffffff memory:14c0b800000-14c0b80ffff memory:e5f00000-e5f7ffff memory:14c0b820000-14c0ba1ffff memory:14c0bc20000-14c0bc9ffff
*-network:0
description: Ethernet interface
product: I350 Gigabit Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:62:00.0
logical name: eth2
version: 01
serial: 6c:b3:11:23:32:18
size: 1Gbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi msix pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.3.0-k duplex=full firmware=1.63, 0x80000cbb ip=94.130.51.145 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
resources: irq:71 memory:e5900000-e59fffff memory:e5a84000-e5a87fff memory:e5a00000-e5a7ffff memory:14c0bf60000-14c0bf7ffff memory:14c0bf40000-14c0bf5ffff
*-network:1 DISABLED
description: Ethernet interface
product: I350 Gigabit Network Connection
vendor: Intel Corporation
physical id: 0.1
bus info: pci@0000:62:00.1
logical name: eth3
version: 01
serial: 6c:b3:11:23:32:19
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi msix pciexpress bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.3.0-k firmware=1.63, 0x80000cbb latency=0 link=no multicast=yes port=twisted pair
resources: irq:82 memory:e5800000-e58fffff memory:e5a80000-e5a83fff memory:14c0bf20000-14c0bf3ffff memory:14c0bf00000-14c0bf1ffff
*-network DISABLED
description: Ethernet interface
physical id: 1
logical name: virbr0-nic
serial: 52:54:00:80:b4:28
size: 10Mbit/s
capabilities: ethernet physical
configuration: autonegotiation=off broadcast=yes driver=tun driverversion=1.6 duplex=full link=no multicast=yes port=twisted pair speed=10Mbit/s
Das erinnert mich daran, dass ich KVM installiert habe
apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils
Aber es ist noch keine VM aktiviert.
Antwort1
Ich hatte ein ähnliches Problem bei der Verwendung von scpoder rsync+ samba/ cifs.
Das Problem wurde auf der rsync+ samba/ cifsSeite behoben, indem der Schreibcache --cache=nonebeim Mounten des Servers auf dem Client umgangen wurde (siehe auchrsync trennt ständig die Verbindung: defekte Pipe). Eine ausführliche Erklärung zur Grundursache dieses Problems finden Sie unterSorgen Sie dafür, dass Linux gleichzeitig mit lokalen Datenträgerlesevorgängen in das Netzwerkdateisystem schreibt.
Sie scpkönnten eine Drosselung der Übertragungsrate in Betracht ziehen, um zu vermeiden, dass der Seitencache gefüllt wird, bevor die Festplatte aufholen kann. Siehe beispielsweisehttps://stackoverflow.com/questions/30020519/broken-pipe-error-on-scp.
Antwort2
Dies war eine „minimal-no-hwe“-Installation. Die „minimale“ Version von Ubuntu hätte höchstwahrscheinlich von Anfang an funktioniert.
Diese Befehle wurden verwendet, um hwe in diese fehlerhafte No-HWE-Version zu installieren (also keine vollständige Neuinstallation):
apt-get install --install-recommends linux-generic-hwe-16.04
shutdown -r now
Danach funktionieren alle SCP-Kopien, keine Abbrüche.
Eine Randbemerkung: Die Begrüßung im Terminal zeigt immer noch
"myuser@Ubuntu-1604-xenial-64-minimal-no-hwe"
obwohl hwe jetzt eingeschaltet ist.
Ich erläutere noch einmal das Verhalten vor diesem Fix: Alle großen SCPs zu dieser Maschine von verschiedenen Standorten wurden abgebrochen, während alle SCPs von dieser Maschine zu verschiedenen Standorten erfolgreich waren.
Dies ist die Serverspezifikationhttps://www.hetzner.de/epyc-serverAllerdings macht der Hoster keine Angaben zu den Modellen für Mainboard/Netzwerk.