And centos6-5 was just reported exhibiting this as well. I've confirmed that the behavior is basically the same as what I saw on centos6-8 last week...
-bash-4.1$ cp -ax workspace/gate-nova-python26.broken testing
-bash-4.1$ cd testing/
-bash-4.1$ git remote -v
origin git://git.openstack.org/openstack/nova (fetch)
origin git://git.openstack.org/openstack/nova (push)
-bash-4.1$ git remote update
Fetching origin
error: fetch died of signal 13
error: Could not fetch origin
-bash-4.1$ git fsck
dangling commit 7015605b3e639350a1a7203b332256e6394014f1
dangling commit 0c47cac76a88edf97d995f01d8f2c52e1c4d8f56
dangling commit e2a225491ccabb5722c57829f65d1951db7cf937
-bash-4.1$ git gc
Counting objects: 215925, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (81823/81823), done.
Writing objects: 100% (215925/215925), done.
Total 215925 (delta 156513), reused 183643 (delta 127638)
-bash-4.1$ git fsck
-bash-4.1$ git remote update
Fetching origin
remote: Counting objects: 656, done.
remote: Compressing objects: 100% (409/409), done.
remote: Total 474 (delta 327), reused 135 (delta 52)
Receiving objects: 100% (474/474), 91.95 KiB, done.
Resolving deltas: 100% (327/327), completed with 66 local objects.
From git://git.openstack.org/openstack/nova 3db4372..852d7c7 master -> origin/master
The fact that we're only seeing this so far with the nova tests on CentOS 6.4 unit test slaves suggests there's something about the version of git client being used there which is exposed/exacerbated by the size of nova's Git repository or the length of time it takes to perform a remote update for it.
As a stop-gap, we might want to make the gerrit-git-prep builder perform a prophylactic 'git gc' before beginning to remote update.
And centos6-5 was just reported exhibiting this as well. I've confirmed that the behavior is basically the same as what I saw on centos6-8 last week...
-bash-4.1$ cp -ax workspace/ gate-nova- python26. broken testing openstack. org/openstack/ nova (fetch) openstack. org/openstack/ nova (push) 0a1a7203b332256 e6394014f1 97d995f01d8f2c5 2e1c4d8f56 722c57829f65d19 51db7cf937 openstack. org/openstack/ nova
3db4372. .852d7c7 master -> origin/master
-bash-4.1$ cd testing/
-bash-4.1$ git remote -v
origin git://git.
origin git://git.
-bash-4.1$ git remote update
Fetching origin
error: fetch died of signal 13
error: Could not fetch origin
-bash-4.1$ git fsck
dangling commit 7015605b3e63935
dangling commit 0c47cac76a88edf
dangling commit e2a225491ccabb5
-bash-4.1$ git gc
Counting objects: 215925, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (81823/81823), done.
Writing objects: 100% (215925/215925), done.
Total 215925 (delta 156513), reused 183643 (delta 127638)
-bash-4.1$ git fsck
-bash-4.1$ git remote update
Fetching origin
remote: Counting objects: 656, done.
remote: Compressing objects: 100% (409/409), done.
remote: Total 474 (delta 327), reused 135 (delta 52)
Receiving objects: 100% (474/474), 91.95 KiB, done.
Resolving deltas: 100% (327/327), completed with 66 local objects.
From git://git.
The fact that we're only seeing this so far with the nova tests on CentOS 6.4 unit test slaves suggests there's something about the version of git client being used there which is exposed/exacerbated by the size of nova's Git repository or the length of time it takes to perform a remote update for it.
As a stop-gap, we might want to make the gerrit-git-prep builder perform a prophylactic 'git gc' before beginning to remote update.