Ошибка соединения 596 broken pipe

Hi!

I am managing a cluster running PVE v6, which currently includes two servers. My third node has been replaced but I am unable to join it.
When I access hv102 using the GUI on hv101, I get «Connection error 596: Broken pipe».
If I try to join hv103, I get this:

Code:

root@hv103 ~ # pvecm add 192.168.120.11 -force
Please enter superuser (root) password for '192.168.120.11': **********
Establishing API connection with host '192.168.120.11'
The authenticity of host '192.168.120.11' can't be established.
X509 SHA256 key fingerprint is 94:DC:85:CD:88:FA:4D:80:8F:CA:37:49:C0:C7:26:4B:5E:EE:28:A8:4B:C0:AD:95:E9:F1:B3:43:2B:6D:3F:C7.
Are you sure you want to continue connecting (yes/no)? yes
500 500 Server closed connection without sending any data back

The pvecm status is fine, I can even run «pvesh get /nodes/hv102/status» from hv101 but I can see it fail, when pveproxy needs to process it for the webif.

This cluster has been updated from v5 in the past but hv103 is a fresh install.

Looks like something is broken. What do I need to do?

Check the journal of all nodes — anything related to problems around the time you tried to join the third node?
look for messages from pveproxy, pmxcfs (pve-cluster), corosync, pvedaemon

No issues, just a restart of the replication service.
What I do not understand is that the status query works using shell and failes when run by pveproxy (when the webif needs the data).
This will most likely be the same issue.

Источник

Hey,

I’m currently working on adding a proxmox node to my proxmox cluster.
I tried everything but it don’t seems to work so I want to ask you guys for help

I installed 2 nodes with the newest proxmox iso
I edited both /etc/hosts configs, so I added node002 to the node001 hosts file and node001 to the node002 hosts file.
I checked if multicast is working with iperf, it’s working finde when I use the multicast address
The 2 nodes are in the same IP Network 31.172.9x.xxx/28

I created a cluster on the 1st node with this command:
pvecm create test
then I tried to add the cluster on my 2nd node with this command:
pvecm add 31.172.9x.x21 —force (IP from the 1st node)

It seems working all fine, there weren’t any errors after I entered the password…

But the problem ist: Node002 appears in the Node002 webinterface, but I can’t manage it: Broken pipe (596)

service corosync status of 1st node (where I created the cluster)

Code:

root@node001:~# service corosync status
● corosync.service - Corosync Cluster Engine
   Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
   Active: active (running) since Sat 2016-08-27 18:14:25 CEST; 30min ago
  Process: 13572 ExecStop=/usr/share/corosync/corosync stop (code=exited, status=0/SUCCESS)
  Process: 13584 ExecStart=/usr/share/corosync/corosync start (code=exited, status=0/SUCCESS)
Main PID: 13593 (corosync)
   CGroup: /system.slice/corosync.service
           └─13593 corosync

Aug 27 18:14:25 node001 corosync[13584]: Starting Corosync Cluster Engine (corosync): [  OK  ]
Aug 27 18:14:51 node001 corosync[13593]: [QUORUM] This node is within the primary component and will provide service.
Aug 27 18:14:51 node001 corosync[13593]: [QUORUM] Members[1]: 1
Aug 27 18:14:56 node001 corosync[13593]: [CFG   ] Config reload requested by node 1
Aug 27 18:15:16 node001 corosync[13593]: [CFG   ] Config reload requested by node 1
Aug 27 18:15:16 node001 corosync[13593]: [QUORUM] This node is within the non-primary component and will NOT provide any services.
Aug 27 18:15:16 node001 corosync[13593]: [QUORUM] Members[1]: 1
Aug 27 18:18:19 node001 corosync[13593]: [TOTEM ] A new membership (31.172.9x.x21:116) was formed. Members
Aug 27 18:18:19 node001 corosync[13593]: [QUORUM] Members[1]: 1
Aug 27 18:18:19 node001 corosync[13593]: [MAIN  ] Completed service synchronization, ready to provide service.

service corosync status on the 2nd node

Code:

root@node002:~# service corosync status
● corosync.service - Corosync Cluster Engine
   Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
   Active: active (running) since Sat 2016-08-27 18:18:19 CEST; 28min ago
  Process: 1383 ExecStart=/usr/share/corosync/corosync start (code=exited, status=0/SUCCESS)
Main PID: 1390 (corosync)
   CGroup: /system.slice/corosync.service
           └─1390 corosync

Aug 27 18:18:18 node002 corosync[1390]: [SERV  ] Service engine loaded: corosync profile loading service [4]
Aug 27 18:18:18 node002 corosync[1390]: [QUORUM] Using quorum provider corosync_votequorum
Aug 27 18:18:18 node002 corosync[1390]: [SERV  ] Service engine loaded: corosync vote quorum service v1.0 [5]
Aug 27 18:18:18 node002 corosync[1390]: [QB    ] server name: votequorum
Aug 27 18:18:18 node002 corosync[1390]: [SERV  ] Service engine loaded: corosync cluster quorum service v0.1 [3]
Aug 27 18:18:18 node002 corosync[1390]: [QB    ] server name: quorum
Aug 27 18:18:18 node002 corosync[1390]: [TOTEM ] A new membership (31.172.9x.217:16) was formed. Members joined: 2
Aug 27 18:18:18 node002 corosync[1390]: [QUORUM] Members[1]: 2
Aug 27 18:18:18 node002 corosync[1390]: [MAIN  ] Completed service synchronization, ready to provide service.
Aug 27 18:18:19 node002 corosync[1383]: Starting Corosync Cluster Engine (corosync): [  OK  ]

pvecm status on the 1st node

Code:

root@node001:~# pvecm status
Quorum information
------------------
Date:             Sat Aug 27 18:47:14 2016
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          0x00000001
Ring ID:          120
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   1
Highest expected: 1
Total votes:      1
Quorum:           1
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 31.172.9x.x21 (local)

pvecm status on the 2nd node

Code:

root@node002:~# pvecm status
Quorum information
------------------
Date:             Sat Aug 27 18:47:54 2016
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          0x00000002
Ring ID:          16
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   1
Highest expected: 1
Total votes:      1
Quorum:           1
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
0x00000002          1 31.172.9x.x17 (local)

/etc/corosync/corosync.conf on the 1st node

Code:

root@node001:~# cat /etc/corosync/corosync.conf
logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: node001
    nodeid: 1
    quorum_votes: 1
    ring0_addr: node001
  }

  node {
    name: node002
    nodeid: 2
    quorum_votes: 1
    ring0_addr: node002
  }

}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: avoro
  config_version: 8
  ip_version: ipv4
  secauth: on
  version: 2
  interface {
    bindnetaddr: 31.172.9x.x21
    ringnumber: 0
  }

}

and on the 2nd node

Code:

root@node002:~# cat /etc/corosync/corosync.conf
logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: node001
    nodeid: 1
    quorum_votes: 1
    ring0_addr: node001
  }

  node {
    name: node002
    nodeid: 2
    quorum_votes: 1
    ring0_addr: node002
  }

}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: avoro
  config_version: 8
  ip_version: ipv4
  secauth: on
  version: 2
  interface {
    bindnetaddr: 31.172.9x.x21
    ringnumber: 0
  }

}

the hosts file on the 1st node

Code:

127.0.0.1 localhost.localdomain localhost
31.172.9x.x21 node001.avoro.eu node001 pvelocalhost
31.172.9x.x17 node002.avoro.eu node002

# The following lines are desirable for IPv6 capable hosts

::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

and the 2nd node

Code:

127.0.0.1 localhost.localdomain localhost
31.172.9x.x17 node002.avoro.eu node002 pvelocalhost
31.172.9x.x21 node001.avoro.eu node001

# The following lines are desirable for IPv6 capable hosts

::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

31.172.9x.x21 is the IP of the 1st Host (Where I created the cluster)
31.172.9x.x17 of the 2nd (Where I tried to add the cluster)

It would be pretty nice if someone could help me

Thanks!

Hey,
thanks for your reply!
This is the result of my test:

Code:

root@node002:~# omping -c 10000 -i 0.001 -F -q node001 node002
node001 : waiting for response msg
node001 : joined (S,G) = (*, 232.43.211.234), pinging
node001 : given amount of query messages was sent

node001 :   unicast, xmt/rcv/%loss = 10000/10000/0%, min/avg/max/std-dev = 0.088/0.153/1.611/0.037
node001 : multicast, xmt/rcv/%loss = 10000/0/100%, min/avg/max/std-dev = 0.000/0.000/0.000/0.000
root@node002:~#

Code:

root@node001:~# omping -c 10000 -i 0.001 -F -q node001 node002
node002 : waiting for response msg
node002 : joined (S,G) = (*, 232.43.211.234), pinging
node002 : waiting for response msg
node002 : server told us to stop
node002 :   unicast, xmt/rcv/%loss = 9842/9842/0%, min/avg/max/std-dev = 0.094/0.148/1.254/0.028
node002 : multicast, xmt/rcv/%loss = 9842/0/100%, min/avg/max/std-dev = 0.000/0.000/0.000/0.000

Best regards
Leif

you have 100% loss of the multicast packages, so this will not work unless you make multicast work

you have 100% loss of the multicast packages, so this will not work unless you make multicast work

I already tried to active it on the node side with

and my network config looks like this on booth nodes (same subnet):

Code:

auto lo
iface lo inet loopback

auto vmbr0
iface vmbr0 inet static
        address 31.172.9x.x21
        netmask 255.255.255.240
        gateway 31.172.9x.x09
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
        post-up ( echo 1 > /sys/devices/virtual/net/$IFACE/bridge/multicast_querier )

Best regards
Leif

Источник

Если вы используете SSH для подключения к удаленным серверам Linux, вы заметите, что если вы оставите сеанс SSH неактивным в течение некоторого времени, а затем попытаетесь использовать его снова, сеанс SSH отключается с сообщением об ошибке, например:

:client_loop: send disconnect: Broken pipe

В некоторых системах отображается сообщение: ‘Write failed: Broken pipe’ or ‘Connection closed by remote host’.

Давайте посмотрим, что вызывает эту ошибку и как сохранить соединение SSH.

Исправление ошибки сломанной трубы с помощью SSH

Как вы уже догадались, соединение SSH закрыто из-за бездействия. Нет установленного значения, но обычно оно составляет около 5 минут или около того.

Что вы можете сделать, чтобы избежать отключения сеанса SSH, – это отправить «живое сообщение» либо с сервера клиенту ( ClientAliveInterval), либо от клиента к серверу ( ServerAliveInterval) через определенный интервал времени.

Таким образом, вы поддерживаете сеанс SSH в активном состоянии, потому что между клиентом и сервером существует связь, и сервер понимает, что клиент все еще существует.

Есть два способа сделать это. Либо вы отправляете живое сообщение от клиента к серверу, либо с сервера клиенту.

Если вы подключаетесь к нескольким серверам через SSH, установите его на своем компьютере.
Если вы системный администратор и несколько пользователей жалуются на частое отключение SSH-соединения, вы можете установить его на сервере.

Метод 1: изменение конфигурации SSH на стороне клиента

Предположим, вы хотите, чтобы ваше SSH-соединение оставалось активным до 10 минут (600 секунд) простоя.

При подключении к удаленной системе Linux через SSH вы можете указать значение ServerAliveInterval:

ssh -o ServerAliveInterval=600 username@server_ip_address

Теперь это работает, но вручную вводить эту опцию каждый раз, когда вы подключаетесь к серверу, утомительно. Почему бы не сделать его постоянным?

Надеюсь, вы знаете о файлах конфигурации SSH. На стороне клиента вы можете воспользоваться этим, чтобы установить определенные параметры SSH для определенных подключений или всех из них.

Во-первых, убедитесь, что у вас есть файл конфигурации ssh. Если не создать:

touch ~/.ssh/config

Важно предоставить ему правильные права доступа к файлам, в противном случае при подключении через SSH у вас будет ошибка отказа в разрешении.

Используйте команду chmod и добавьте к ней следующие права доступа к файлу:

chmod 600 ~/.ssh/config

Если вам лень или вы не хотите вдаваться в подробности, используйте эту команду, чтобы установить интервал активности на 600 секунд (10 минут):

echo "ServerAliveInterval 600" >> ~/.ssh/config

Это установит значение ServerAliveInterval на 10 минут для всех SSH-соединений, которые вы будете использовать. Попробуйте, если хотите.

Если вы хотите сделать его более правильным, вы должны добавить его так:

Host *
ServerAliveInterval 600

Метод 2: изменение конфигурации SSH на стороне сервера

Файл конфигурации SSH для сервера обычно находится в /etc/ssh/sshd_config.

Если вы откроете этот файл, вы найдете здесь два интересующих параметра:

ClientAliveInterval: Это период времени бездействия, по истечении которого сервер отправит сообщение об активности подключенному по ssh клиенту.
ClientAliveCountMax: Это количество попыток, которые сервер сделает для отправки живого сообщения.

Скажем, вы установили ClientAliveInterval в 200 секунд и ClientAliveCountMax в 3. Это означает, что сервер отправит живое сообщение через 200 секунд. Если со стороны клиента нет активности, он снова отправит живое сообщение через 400 секунд. Нет ответа/активности от клиента, и другое живое сообщение отправлено через 600 секунд. По истечении этого времени (600 секунд) соединение SSH прерывается.

Вы можете отредактировать файл /etc/ssh/sshd_config в своем любимом текстовом редакторе на базе терминала, таком как Vim. Найдите записи ClientAliveInterval и ClientAliveCountMax. Удалите ключ # в начале строк и присвойте им соответствующее значение.

Исправление ошибки сломанной трубы с помощью SSH-соединения

Сохраните и выйдите из файла.

Пожалуйста, не устанавливайте тайм-аут SSH-соединения на несколько часов. Это было бы пустой тратой ресурсов.

Мы надеемся, что эта статья помогла вам решить проблему с ошибкой сломанной трубы при SSH-соединении. Ваше мнение приветствуется.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

If you use SSH to connect to remote Linux servers, you’ll notice that if you keep your SSH session inactive for some time and then try to use it again, the SSH session disconnects with an error message like this:

:client_loop: send disconnect: Broken pipe

On some systems, it will display ‘Write failed: Broken pipe’ or ‘Connection closed by remote host’.

Let’s see what causes this error and how to go about keeping your SSH connection alive.

Fixing broken pipe error with SSH

As you may have guessed, the SSH connection is closed because of inactivity. There is no set value but it usually around 5 minutes or so.

What you can do to avoid the SSH session disconnection is to send an ‘alive message’ either from the server to client (ClientAliveInterval) or from client to server (ServerAliveInterval) at certain time interval.

This way, you keep the SSH session alive because there is a communication between the client and server and the server understands that client is still there.

Now, there are two ways to do that. Either you send the alive message from the client to the server or from the server to the client.

If you connect to multiple servers via SSH, set it on your machine.
If you are a sysadmin and several of users complain about frequent SSH connection disconnect, you may set it on the server.

Method 1: Client side SSH configuration change

Let’s say you want to keep your SSH connection alive with up to 10 minutes (600 seconds) of idle time.

While connecting to the remote Linux system through SSH, you can mention the ServerAliveInterval value like this:

ssh -o ServerAliveInterval=600 [email protected]_ip_address

Now, this thing work but manually entering this option each time you connect to the server is tiresome. Why not make it permanent?

I hope you are aware of the SSH config files. On the client side, you can take advantage of it to set certain SSH parameters for specific connections or all of them. I have explained SSH config file in detail here.

First, make sure that you have the ssh config file. If not create it:

touch ~/.ssh/config

It is important to give it the correct file permissions otherwise you’ll have permission denied error while connecting via SSH.

Use the chmod command and add the following file permission to it:

chmod 600 ~/.ssh/config

If you’re feeling lazy or don’t want to go in detail, use this command to set the alive interval to 600 seconds (10 minutes):

echo "ServerAliveInterval 600" >> ~/.ssh/config

This will set the ServerAliveInterval value to 10 minutes for all SSH connection you’ll use. Give it a try if you want to.

If you want to make it more proper, you should add it like this:

Host *
ServerAliveInterval 600

Method 2: Server side SSH config change

The SSH config file for the server is usually located at /etc/ssh/sshd_config.

If you open this file, you’ll find two parameters of interest here:

ClientAliveInterval: This is the inactivity time period after which the server will send an alive message to the ssh connected client.
ClientAliveCountMax: This is the number of attempts the server will make to send the alive message.

Say, you set ClientAliveInterval to 200 seconds and ClientAliveCountMax to 3. This means the server will send alive message after 200 seconds. If there is no activity from the client, it will again send an alive message at 400 seconds. No response/activity from the client and another alive message is sent at 600 seconds. After this (600 seconds) the SSH connection is disconnected.

You can edit the /etc/ssh/sshd_config file in your favorite terminal based text editor like Vim. Look for ClientAliveInterval and ClientAliveCountMax entries. Remove the # key at the beginning of the lines and give them the appropriate value.

Save and exit the file.

Please do not set the SSH connection timeout to several hours. That would be a waste of resources.

I hope this tutorial helped you to fix the broken pipe error issue with SSH connection. Your feedback is welcome.

Abhishek Prakash

Creator of Linux Handbook and It’s FOSS. An ardent Linux user & open source promoter. Huge fan of classic detective mysteries from Agatha Christie and Sherlock Holmes to Columbo & Ellery Queen.

Источник