5

Edit on September 28, 2017. The error description you'll read below makes the problem appear to be GitLab or OS specific. The behavior described can be encountered on any computer behind a proxy while attempting to connect to any internally hosted Git server, whether GitHub, GitLab, Bitbucket, etc... .

I have a RHEL6 server (setup by the corporate server team) that I installed GitLab Community Edition 7.9.2 on following the instructions provided by GitLab here. After following the installation instructions I was able to start the server and login.

I created a group and a project, then I forked into my own account. I can create a file through the GitLab UI and commit it. I'm trying to fetch from my forked project using Git Bash (on Windows 7) and with SourceTree but I'm getting this error:

git -c diff.mnemonicprefix=false -c core.quotepath=false fetch origin fatal: unable to access 'http://server.domain.com/username/project.git/': The requested URL returned error: 503

Most documentation I've found says this is a temporary thing and should be resolved soon. I am the only person using this server, this is the only thing it has installed, and the issue has lasted all day.

I've tried running reconfigure commands on GitLab with no effect. Gitlab or ngenix isn't an installed service so I'm not able to restart them.

Another tidbit here is that I'm a newbie at Linux server management, I haven't touched Linux in 7 years.

Any ideas?

7
  • HTTP 503 is "service unavailable". You should probably start by looking at your web server and application logs to see what's going on. Commented Apr 6, 2015 at 18:13
  • The logs look empty, I found the nginix and other GitLab logs. The logs have rolled over a few times and were zipped but they are all 0 bytes. Commented Apr 6, 2015 at 19:36
  • There should at least be a mention of the 503 errors... Have you looked at the -error.log files? Commented Apr 6, 2015 at 19:40
  • I would expect to see some log entries for it as well but I do not. I'm running a grep to find a 503 reference now. Commented Apr 6, 2015 at 20:12
  • 1
    I found another post that suggested proxy settings can get in the way. I had a friend clone the repo who sits in a different building than I do and he cloned it. I opened a request to my company's help desk to look into the network/proxy settings with me. Commented Apr 7, 2015 at 21:04

3 Answers 3

11

The problem turned out to be a proxy setting set as a system property. That overrides the gitconfig settings. Once I removed this it was able to work properly.

You can also set an environment variable for no_proxy with your GH url included.

Sign up to request clarification or add additional context in comments.

7 Comments

Can you explain de little more ?
The Git command line will return a 503 error if it is not able to communicate with the server specified in the remote. If you're behind a company proxy then the command maybe filtered and not pass through the proxy to the server. In my case it was an internal server but the proxy was still being hit. I had to disable proxy proxy settings to be able to hit the server. If you switch to SSH you shouldn't run into this type of problem.
What environment variable did you set?
@fedorqui You can add a no_proxy variable with the URL(s) for your company so that the traffic to your Git server is not routed through the proxy first (and lost, which returns the 503).
Funny thing is that (as you expose in your first comment) git clone works with SSH, but not with HTTP, where I get the 503. I cannot understand what you mean with add a no_proxy variable with the URL(s). How would I do that? I see options to wget or curl with a no_proxy option, but it might not be what you mean. Thanks for answering!
|
8

This problem is not only created by no_proxy, because it created by git server down issue also.

So When happening this issue first you open and check gitlab in browser.

And check if It shows any error like "503 An internal server error occured". .

The gitlab shows "503" page, this issue create by gitlab server down not in your system.

So you wait some time until the server going up and continue your work.

1 Comment

Most likely explanation. Just went to the GL site: 503 "We are performing a scheduled maintenance". But, as per the other answers, why not try to solve a problem on your own system first before checking, just to complicate your life?
2

I encountered an 503 Error and this command helps me to find the element that causes error :

gitlab-rake gitlab:check 

It displays the following output (truncated) :

Gitaly: ... default ... FAIL: 14:Connect Failed Checking Gitaly ... Finished Checking Sidekiq ... Sidekiq: ... Running? ... yes Number of Sidekiq processes ... 1 Checking Sidekiq ... Finished Checking Incoming Email ... Incoming Email: ... Reply by email is disabled in config/gitlab.yml Checking Incoming Email ... Finished Checking LDAP ... LDAP: ... LDAP is disabled in config/gitlab.yml Checking LDAP ... Finished 

1 Comment

Facing same issue. have you got the solution?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.