Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Apologies if this isn't the right stackexchange.

I have a GitLab install. It was installed over the top of a gitolite install that was only a few days old, and I assume this non-standard setup is at the root of my problem, but I cannot pin it down.

The problem is straightforward: post-receive hooks are not fired. This prevents 'project activity' appearing in GitLab. The problem looks like:

$ git push
error: cannot run hooks/post-receive: No such file or directory

Hook Exists

The post-receive hook/symlink exists and is executable:

-rwxr-xr-x 1 git git 470 Oct  3  2012 .gitolite/hooks/common/post-receive
lrwxrwxrwx 1 git git  45 Oct  3  2012 repositories/project.git/hooks/post-receive -> /home/git/.gitolite/hooks/common/post-receive

It's Executable By GitLab

The gitlab user can execute the script (I have removed the /dev/null redirect and fed in blank input to get an 'OK' as output):

sudo su - gitlab -c /home/git/.gitolite/hooks/common/post-receive


GitLab Can Find It

GitLab is looking for hooks in the correct location:

$ grep hooks /srv/gitlab/gitlab/config/gitlab.yml
  hooks_path: /home/git/.gitolite/hooks/


$ bundle exec rake gitlab:app:status RAILS_ENV=production
# ...
/home/git/.gitolite/hooks/common/post-receive exists? ............YES

GitLab Runs As Correct User

The GitLab software is being run by the gitlab user:

$ ps U gitlab
 3650 ?        Sl     0:59 unicorn_rails master -c /srv/gitlab/gitlab/config/unicorn.rb -E production -D
 3671 ?        Sl     0:43 unicorn_rails worker[0] -c /srv/gitlab/gitlab/config/unicorn.rb -E production -D
 3674 ?        Sl     0:42 unicorn_rails worker[1] -c /srv/gitlab/gitlab/config/unicorn.rb -E production -D
# ...


The env -i line in the hook is commonly cited as an issue. I think that would occur after this problem, but for completeness, redis-cli is found OK:

$ env -i redis-cli

I've run out of debugging ideas on this one. Does anybody have any suggestions?

share|improve this question
up vote 3 down vote accepted

OK, figured this one out. It's remotely possible this situation will apply to other people, so I've documented it.

Our infrastructure has all external SSH connections landing on a particular machine1. This isn't the machine running gitlab. This wasn't obvious because gitolite+gitlab works despite this. Our homedirs are NFS mounts and both the SSH machine and the gitlab machine see the gitolite files as 'local'. The one problem with this 'distributed' gitolite+gitlab is that the post-receive hook tries to call redis-cli, a binary which doesn't exist on the machine running the hook.

To solve the problem, I installed the redis-server package on the machine accepting SSH connections (unfortunately the redis-cli binary doesn't appear to be available separately). I then modified the redis line in /home/git/.gitolite/hooks/common/post-receive to the following:

redis-cli -h hostname rpush "resque:queue:post_receive" "{\"class\":\"PostReceive\",\"args\":[\"$reponame\",\"$oldrev\",\"$newrev\",\"$ref\",\"$GL_USER\"]}" > /dev/null 2>&1

The -h hostname switch is the only addition. This causes the redis rpush command to be sent to redis on the correct machine.

The missing binary error didn't surface due to the > /dev/null 2>&1 redirect in the hook script. Although I did remove it during debugging, I must have restored it before I attempted to trigger the hook via a git push, which otherwise would have echoed the error.

My assumption about my slightly nonstandard gitlab installation turned out to be incorrect. This problem would have occured regardless; it's due to a networking quirk. Anyhow, I hope this will be of use to somebody.

  1. In the case of git, we use external URLs even within the local network so that project URLs are consistent regardless of network environment.
share|improve this answer

I had the same issue but the reason was different.

My redis installation was at /usr/local/bin. Git user had it in its PATH, but with no effect.

I had to make it obvious in script to start redis from /usr/local/bin/redis-cli:

env -i /usr/local/bin/redis-cli rpush "resque:queue:post_receive" "{\"class\":\"PostReceive\",\"args\":[\"$reponame\",\"$oldrev\",\"$newrev\",\"$ref\",\"$GL_USER\"]}"  > /dev/null 2>&1

It solved my issue with post-receive hook not firing.

I hope this will be helpful for someone else too.

share|improve this answer
I believe it's the env -i switch causing your problem: "start with an empty environment". There is a bug report here: – Ben Graham Nov 15 '12 at 22:47
Well, you are definitely right. Here this issue marked as fixed: #621, but my GitLab 3 fresh install did not have this patched post-recieve hook. Perhaps this is because I previously had Gitolite installation. – Клаус Шварц Nov 29 '12 at 4:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.