jruff's picture

I installed the GitLab 13.0 ISO to a Proxmox-VE virtual machine. I then rebooted and went through all of the turnkey-init configurations, including the initial package updating and rebooted. No other changes have been made. When I try to use a browser to open <host ip addr>, I get back "502 Bad Gateway". I have googled around, but have not found anything to help. <host ip addr>:12321 opens and works properly.

Any ideas would be greatly appreciated;

John

Forum: 
Jeremy Davis's picture

Thanks for reporting. I have added a bug report to the TKL Issue Tracker. I'll have a quick look when I get a chance to see if there is perhaps a quick workaround. Sorry that I can't do it straight away.

Carles Mateu's picture

Same situation. A vanilla new virtual machine with TKL Gitlab 13.0. And I'm getting the same error.  A web connection to / is redirected to /users/sign_in, where the 502 error is shown. On the  gitlab/logs/*log this is what appears:

==> production.log <==

Started GET "/users/sign_in" for 193.144.12.5 at 2015-01-21 08:31:46 +0000
Processing by Devise::SessionsController#new as HTML
  Rendered devise/sessions/new.html.haml within layouts/devise (30.8ms)

==> unicorn.stderr.log <==
E, [2015-01-21T08:32:16.934330 #2353] ERROR -- : worker=1 PID:29390 timeout (31s > 30s), killing
E, [2015-01-21T08:32:16.963744 #2353] ERROR -- : reaped #<Process::Status: pid 29390 SIGKILL (signal 9)> worker=1
I, [2015-01-21T08:32:16.977034 #29769]  INFO -- : worker=1 ready

Jeremy Davis's picture

Apologies about that. My guess is that there is that one of the auto updates is breaking things. I will have a look at it when I get a chance.

David Johnson's picture

Hi,

Just setup an AWS instance and getting the fault straight away.

Jeremy Davis's picture

After having a read of that thread I recall testing the GitLab appliance some time ago and having a similar issue - that was resolved with more RAM. I had totally forgotten about that. I recall discussing it here in the forums but a quick search didn't bring it up. Anyway it prompted me to do a little more reading too...

It seems that the 502 Nginx error is a resource issue (as per your link David). It can be worked around to a point but here is what GitLab devs say about RAM requirements. Bottom line is that anything less that 1GB and it probably won't work OOTB unless you tweak some settings...

If any of you that are experiencing this issue that are using VMs could please give your TKL GitLab VM 1GB RAM + 1GB swap (or more) and retest? Then we can hopefully confirm that this is a resource issue.

If need be I will do this test myself when I get a chance...

Jeremy Davis's picture

And I can confirm this 'bug' with 512MB RAM (even with 1.5GB of swap - but without any confi changes). However I can also confirm that it works as expected (OOTB) with 1GB RAM and 1GB swap...!

So essentially this is not a bug, but relates to minimum spec requirements. If you wish to run GitLab with less than 1GB of RAM you will need to play with the config - and even then there are no guarantees...

I will also update and close the issue on GitHub...

Georgio's picture

Just for anyone else out there getting stuck. Here is what you do as long as there is no update available:

  • Install turnkey-gitlab_14.0
  • Run through the installation steps
  • Log into the SSH-shell or web shell
  • run the following commands

cp /home/git/gitlab/lib/support/init.d/gitlab /etc/init.d/gitlab
chown root:root /etc/init.d/gitlab
update-rc.d gitlab defaults
update-rc.d gitlab enable

shutdown -r now

After the reboot everything should work as expected.

Georgio's picture

...RAM was no issue in my tests. Runs just fine with 512MB.

Jeremy Davis's picture

Actually that was a known issue in v14.0 but only affected systems using SysVInit (only used in Proxmox/LXC and OpenStack builds).

FWIW it will be fixed in v14.1 when it's released (very soon...)

eisco's picture

i still get this problem with 4GB of ram and two cores, so i think the problem is still there.

Jeremy Davis's picture

It often takes a few minutes to start. Did you wait for a little while...?
eisco's picture

I will wait a bit longer, how long does it take to be started?

I run it under proxmox.

Jeremy Davis's picture

There is a bug in the v14.0 LXC GitLab appliance. When we originally built it we only included a SystemD initscript; but then we had issues with SystemD inside containers. As a workaround we rep-laced SystemD with SysV but didn't include a SysV initscript.

It has been patched and a fixed version will be released as part of v14.1 which should be soon.

In the meantime if you want to have a look at it yourself this is the commit: https://github.com/turnkeylinux-apps/gitlab/commit/a9af3969640938d286046...

vialcollet's picture

Hi there 

I don't know if this is the same issue but I found this issue on github:

https://github.com/gitlabhq/gitlabhq/issues/9936

 

I did the following change and then my lxc container (ubuntu 14 and omnibus install) in proxmox worked.

# gitlab_workhorse['listen_addr'] = "/var/opt/gitlab/gitlab-workhorse/socket"

changed to:

gitlab_git_http_server['listen_addr'] = '/tmp/gitlab-workhorse.socket'

Then

sudo gitlab-ctl reconfigure
Jeremy Davis's picture

Thanks for trying to help out but I doubt that this is the same issue. In TurnKey Linux (these are the TurnKey Linux support forums) we do not enable AppArmor by default in any appliance, including the GitLab appliance.
vialcollet's picture

I had tried the Turnkey appliance but also got this Bad Gateway issue.

Then I installed a git myself in a container and got the same issue that I solved as I reported above. As this seems to be linked to AppArmor on the host, I thought this may also apply to the Turnkey appliance.

Thanks for your answer.

Add new comment