Git: нажатие подписанного коммита завершает все операции

Question

Я использую разные репозитории git для управления версиями исходного кода, клонированные из разных исходных кодов (например, GitHub.com, gitlab.com, самостоятельно размещенный gitlab и т.д.), Все с доступом по SSH-ключу. git pull всегда работает, но после того, как я создаю новый коммит, используя

touch test && git add . && git commit -a -m "Test"

git push всегда будет находиться в тайм-ауте во всех репозиториях со всеми исходными версиями. После этого все другие операции git, связанные с удаленным компьютером (git clone , git pull , ...), также будут отключаться, даже в других репозиториях с другими потоками uspt.

Однако по умолчанию я использую коммиты со знаком gpg. Если я отключу это, установив

git config --global commit.gpgsign false

удалите мои локальные репозитории с новыми коммитами, снова клонируйте их и создайте новые беззнаковые коммиты, отправляя работы.

Так что, похоже, это связано с подписанием коммита. Есть идеи? На моей другой машине, которая настроена таким же образом (те же версии программного обеспечения, те же самые конфиги), работает нажатие подписанных коммитов.

РЕДАКТИРОВАТЬ: Как и предполагалось в коммитах, я проверил эту проблему с коммитами, которые не зашифрованы, но имеют большие сообщения коммитов и, что интересно, получили ошибки при фиксации сообщений около 4 КБ. Так, может быть, эта проблема связана с размером сообщений фиксации?

Answer 1

Путь от вас до сервера GitLab имеет ссылку с MTU ниже, чем у стандартного 1500. (Это может быть любой маршрутизатор или конечный сервер.) Дополнительно,

• либо рассматриваемая система не отправляет вам сообщения об ошибках ICMP "Packet Too Big",
• или ваш компьютер не получает их (потому что они заблокированы другим маршрутизатором в середине),
• или ваш компьютер сам блокирует / игнорирует их (чрезмерно усердный iptables-ing).

Это приводит к зависанию компьютера при отправке больших IP-пакетов (сегментов TCP): он не получает ACK TCP, но также не получает сообщение об ошибке ICMP, поэтому все, что он может сделать, это продолжать повторять попытки.

(Если он получил "пакет слишком большой" пакет ICMP, он будет автоматически регулировать MTU для конкретного назначения и повторной отправки пакета в более мелкие фрагменты - это называется "Path MTU Discovery").

Расследование PMTUD

Сбросьте свой MTU до стандартного 1500, затем запустите Wireshark или tcpdump для захвата пакетов "icmp or icmp6" . После того, как вы попытаетесь нажать еще раз, и соединение зависнет, при перехвате пакетов должны отображаться либо некоторые входящие пакеты ICMP, либо просто исходящие повторные передачи TCP.

Если вы видите входящие ответы ICMP "Пакет слишком большой", обычно проблема заключается в вашем собственном брандмауэре, который без необходимости блокирует ICMP. Если вы этого не видите, проблема где-то еще выше по течению.

(Вы также можете протестировать tracepath на сервере GitLab, хотя сам этот инструмент опирается на ICMP, поэтому он покажет что-нибудь полезное, только если PMTUD уже работает.)

Исправление локальной блокировки ICMP

Откройте свой набор правил iptables/nft и удалите слишком широкие правила "блокировать все ICMP", если они есть. (См. Http://shouldiblockicmp.com/ для списка необходимых / разрешенных типов / подтипов.)

Обходные пути для проблем MTU вверх по течению

В Linux в дополнение к PMTUD на основе ICMP вы также можете использовать обнаружение MTU на уровне TCP:

sudo sysctl net.ipv4.tcp_mtu_probing=1

Это не зависит от каких-либо сообщений об ошибках, оно просто сообщает TCP, что всякий раз, когда он обнаруживает потерю пакета после отправки больших сегментов, он должен повторно передавать с меньшими (вместо повторной отправки точно так же, как раньше). Соединение TCP все еще будет зависать на секунду или две, прежде чем настраивать MSS и возобновлять работу.

Вы также можете использовать iptables «TCP MSS-фиксация», чтобы в TCP-соединениях с самого начала использовался меньший максимальный размер сегмента.