问题
the last days I read alot of posts with the same problem. Some with an solution, but nothing worked for me.
After updating to 6.9.0 through the update-script, when I push, I get
POST git-receive-pack (896 bytes)
remote: /usr/local/lib/ruby/2.0.0/net/protocol.rb:158:in `rescue in rbuf_fill': Net::ReadTimeout (Net::ReadTimeout)[K
remote: from /usr/local/lib/ruby/2.0.0/net/protocol.rb:152:in `rbuf_fill'[K
remote: from /usr/local/lib/ruby/2.0.0/net/protocol.rb:134:in `readuntil'[K
remote: from /usr/local/lib/ruby/2.0.0/net/protocol.rb:144:in `readline'[K
remote: from /usr/local/lib/ruby/2.0.0/net/http/response.rb:39:in `read_status_line'[K
remote: from /usr/local/lib/ruby/2.0.0/net/http/response.rb:28:in `read_new'[K
remote: from /usr/local/lib/ruby/2.0.0/net/http.rb:1406:in `block in transport_request'[K
remote: from /usr/local/lib/ruby/2.0.0/net/http.rb:1403:in `catch'[K
remote: from /usr/local/lib/ruby/2.0.0/net/http.rb:1403:in `transport_request'[K
remote: from /usr/local/lib/ruby/2.0.0/net/http.rb:1376:in `request'[K
remote: from /home/git/gitlab-shell/lib/gitlab_net.rb:76:in `block in get'[K
remote: from /usr/local/lib/ruby/2.0.0/net/http.rb:852:in `start'[K
remote: from /home/git/gitlab-shell/lib/gitlab_net.rb:76:in `get'[K
remote: from /home/git/gitlab-shell/lib/gitlab_net.rb:31:in `allowed?'[K
remote: from /home/git/gitlab-shell/lib/gitlab_update.rb:39:in `exec'[K
remote: from hooks/update:14:in `<main>'[K
remote: error: hook declined to update refs/heads/master[K
Pushing to http://xyz/xyz/test.git
To http://xyz/xyz/test.git
! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'http://xyz/xyz/test.git'
The Repo is newly created. It's empty, I try to push new Files. Also this problem occures on existing Repos.
Here some Server-Infos:
root@v22014011205216285:/home/git/gitlab# sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production
System information
System: Debian 7.5
Current User: git
Using RVM: no
Ruby Version: 2.0.0p247
Gem Version: 2.0.3
Bundler Version:1.5.1
Rake Version: 10.3.1
Sidekiq Version:2.17.0
GitLab information
Version: 6.9.0
Revision: f0a32c6
Directory: /home/git/gitlab
DB Adapter: mysql2
URL: http://xyz
HTTP Clone URL: http://xyz/some-project.git
SSH Clone URL: git@xyz:some-project.git
Using LDAP: no
Using Omniauth: no
GitLab Shell
Version: 1.9.4
Repositories: /home/git/repositories/
Hooks: /home/git/gitlab-shell/hooks/
Git: /usr/bin/git
root@v22014011205216285:/home/git/gitlab# sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production
Checking Environment ...
Git configured for git user? ... yes
Checking Environment ... Finished
Checking GitLab Shell ...
GitLab Shell version >= 1.9.4 ? ... OK (1.9.4)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by git:git? ... yes
Repo base access is drwxrws---? ... yes
Satellites access is drwxr-x---? ... yes
update hook up-to-date? ... yes
update hooks in repos are links: ...
xyz / 1 ... ok
[...]
xyz / 2 ... ok
Running /home/git/gitlab-shell/bin/check
Check GitLab API access: OK
Check directories and files:
/home/git/repositories: OK
/home/git/.ssh/authorized_keys: OK
Test redis-cli executable: redis-cli 2.4.14
Send ping to redis server: PONG
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Sidekiq ...
Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking LDAP ...
LDAP is disabled in config/gitlab.yml
Checking LDAP ... Finished
Checking GitLab ...
Database config exists? ... yes
Database is SQLite ... no
All migrations up? ... yes
Database contains orphaned UsersGroups? ... no
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Init script exists? ... yes
Init script up-to-date? ... yes
projects have namespace: ...
xyz / 1 ... yes
[...]
xyz / 2 ... yes
Oliver Lippert / test ... yes
Projects have satellites? ...
xyz / 1 ... yes
[...]
xyz / 2 ... yes
Redis version >= 2.0.0? ... yes
Your git bin path is "/usr/bin/git"
Git version >= 1.7.10 ? ... yes (1.7.10)
Checking GitLab ... Finished
The update-hook is an symlink to the standard gitlab-shell update-script
#!/usr/local/bin/ruby
# This file was placed here by GitLab. It makes sure that your pushed commits
# will be processed properly.
# You can add your own hooks to this file, but be careful when updating gitlab-shell!
refname = ARGV[0]
key_id = ENV['GL_ID']
repo_path = Dir.pwd
#repo_path = `pwd`
require_relative '../lib/gitlab_update'
GitlabUpdate.new(repo_path, key_id, refname).exec
(I think I have done one or two little things, but the problem was before and after my small changes).
May someone can help me analysing and fixing this Problem?
Thanks for any Feedback.
PS: I have opened up an Issue here some days ago: https://github.com/gitlabhq/gitlabhq/issues/6978
I also do have an second GitLab-Instance updated to 6.9.0, it is running without any problems ?
回答1:
I don't know if this can help someone, but i've found a solution for this « bug ».
in your repository folder /home/git/repositories/user/project_name.git/hooks/update, just replace the first line :
#!/usr/local/bin/ruby
by this :
#!/usr/bin/env ruby
This saved me so I hope it can helps others.
回答2:
For me the problem was that I've configured unicorn to start just one worker process.
Unicorn starts a GET-Request to figure out if the currently pushing user is allowed to push. Without a second worker this request is never being answered.
回答3:
I meet the same error, my solution is disable update file temporarily, after push done, enable it
回答4:
Try to set PermitUserEnvironment value
回答5:
The following steps helped remediate the issue
- Removing the origin by using
git remote rm origin - Adding the origin back by using
git remote add origin https://github.com/<repo_name> - Checking if the remote is now set by using
git remote -v - Trying to do
git push origin <branch>again
来源：https://stackoverflow.com/questions/23867877/gitlab-6-9-0-hook-declined-to-update-refs-heads-master