У меня есть следующая структура звонка:
- Дженкинс бежит
fab -Huser@host set_repository_commit_hash:123abc
. set_repository_commit_hash
работаетgit fetch
сpty = False
.- Дочерний процесс
ssh git@github.com git-upload-pack 'user/repository.git'
никогда не заканчивается.
Я попытался запустить git fetch
в локальном клоне, и это успешно, но запуск ssh git@github.com git-upload-pack 'user/repository.git'
только возвращает следующее и зависает:
00ab84249d3bb20930c185c08848c60b71f7b28990d6 HEADmulti_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed agent=git/1.8.4
0041cb34b1c8ca75d478df38c794fc15c5f01cc6377e refs/heads/branch_name
004012577068adf47015001bfa0cff9386d6cdf497ce refs/heads/[...]
003f84249d3bb20930c185c08848c60b71f7b28990d6 refs/heads/master
[a couple more lines like the ones above, then:]
0000
Это известная проблема SSH / Git / Fabric / Jenkins?
Я сделал strace
это, но я не записал сессию. Я считаю, что это застряло на read
.
Возможно соответствующие ссылки:
- Выпуск Jenkins 14752: опрос SCM / максимальное число одновременных опросов = 1 зависает опрос github
- Почему git-upload-pack (во время git clone) зависает?
- выпуск tortoisegit 1880: сборка tortoisegit зависает из-за работающей / никогда не исчезающей tortoisegitplink (особенно комментарий № 7 )
- Что это за случайный бесконечный процесс git-upload-pack?
git-upload-pack
должно делать, AFAICT. Он ждет, когда вы поговорите по протоколу git fetch-pack и сообщите ему, что отправлять (попробуйте запустить его в локальном репозитории, вы получите тот же вывод).
git clone
(от github) работа на хосте, который пытается получить Jenkins? Я подозреваю, что это не так, и у вас, вероятно, есть проблема с обнаружением Path MTU, вызванная сломанным брандмауэром (который может быть где угодно на пути - не только на вашей стороне)
strace -p <pid of hung git daemon>
что это блокирует?