Atualização 1

Atualização 1

tópicos relacionados

Meu problema é semelhante, mas não exatamente igual aPipe quebrado SSH, código de autenticação de mensagem incorretopara o qual não há resposta.

Tarefa

Copie arquivos grandes de um Linux para outro. Ambos estão no mesmo local do ISP.

Configurar

A origem e o destino são: Ubuntu 16.04.3 LTS

Versão SSH em ambos: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 de março de 2016

A máquina de origem está em uso há um ano, sem problemas. A máquina de destino é um servidor dedicado recém-configurado (1 dia).

comando scp:

scp -P [customport] /some/large/file user@targetmachine:/target/folder/

O arquivo tem cerca de 20 GB de tamanho.

Descrição do Problema

Geralmente aborta após cerca de 3-4%. A velocidade total é de cerca de 112 MB/s. Quando eu acelero, por exemplo, scp -l 16384, ele atinge cerca de 2 MB/s, aborta muito mais tarde, mas em uma porcentagem semelhante.

O aborto é sempre exatamente da mesma maneira. O cliente obtém:

Write failed: Broken pipe 
lost connection

Enquanto o servidor tiver isso em /var/log/auth.log

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

Investigação

Eu tentei ambos com o iptables ativado e desativado, sem alterações.

Das cerca de 10 tentativas, 1 foi bem-sucedida até o fim e o próximo arquivo foi abortado novamente.

Parece que após reiniciar a máquina de destino, mais bytes podem ser gravados nela.

SSH não é problema. Posso manter uma conexão ssh ociosa aberta por horas ou uma em que o topcomando esteja em execução e não seja interrompido.

Questões

Este é um bloqueador. Primeiro, parece impossível copiar um arquivo de 200 GB. Segundo, não quero uma máquina em produção com problemas de rede.

O que posso fazer para investigar isso mais detalhadamente?

Li em outro lugar que pode ser um problema de placa de rede/hardware. Como posso provar isso ao meu provedor para obter uma substituição?

Atualização 1

O resultado por 10 minutos mtrparece bom:

└─(~)─(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)

Logo depois tentei outro scp, ele falhou em 44% após 7,5 GB, a taxa era de 111 MB/seg. A falha novamente veio instantaneamente, sem nenhuma paralisação antes disso.

Quanto à possível duplicata: sempre recebi o "tubo quebrado", nunca o "Protocolo tipo errado para soquete". Não uso Mac, ambos Linux (versões acima). Não usando rsync. A resposta foi que o usuário colocou outra placa de rede no servidor, sem descobrir qual era a real causa, pelo que entendi. Não tenho essa opção (servidor dedicado em centro de host remoto).

Aqui está a saída do lshw em relação à placa de rede:

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

Isso me lembra, eu instalei o KVM

apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

Mas nenhuma VM está ativada ainda.

Responder1

Eu tive um problema semelhante ao usar scpou rsync+ samba/ cifs.

O problema foi resolvido no lado rsync+ samba/ cifsignorando o cache de gravação usado --cache=noneao montar o servidor no cliente (veja tambémrsync continua desconectando: tubo quebrado). Uma explicação detalhada sobre a causa raiz deste problema é fornecida emFaça o Linux gravar no sistema de arquivos da rede simultaneamente com leituras de disco local.

Com scpvocê, você poderia considerar limitar a taxa de transferência para evitar preencher o cache da página antes que o disco pudesse alcançá-lo, veja, por exemplohttps://stackoverflow.com/questions/30020519/broken-pipe-error-on-scp.

Responder2

Esta foi uma instalação "mínima sem necessidade". A versão “mínima” do Ubuntu provavelmente teria funcionado desde o início.

Esses comandos foram usados ​​para instalar o hwe nesta versão no-hwe com defeito (portanto, nenhuma reinstalação completa):

apt-get install --install-recommends linux-generic-hwe-16.04
shutdown -r now

Depois disso, todas as cópias do scp funcionam, sem interrupções.

Uma observação lateral: a saudação no terminal ainda mostra

"myuser@Ubuntu-1604-xenial-64-minimal-no-hwe"

mesmo que esteja ligado agora.

Esclareço mais uma vez o comportamento antes desta correção: Todos os scp grandes PARA esta máquina, de vários locais, foram abortados, enquanto todos os scp desta máquina, para vários locais, foram bem-sucedidos.

Esta é a especificação do servidorhttps://www.hetzner.de/epyc-serverembora o hoster não especifique os modelos para placa-mãe/rede.

informação relacionada