Hi guys, we have an Ubuntu with Gitlab.
One user complaining got 500 error. And rebooted the server.

Before rebooting the server, the https://192.168.1.50 was showing the Gitlab web page.

After rebooting, Gitlab web page is not showing up.

Nginx seems to be running.

I got these when I run sudo gitlab-ctl status

ok: run: gitaly: (pid 5392) 1s
ok: run: gitlab-monitor: (pid 5416) 0s
ok: run: gitlab-workhorse: (pid 5421) 1s
ok: run: logrotate: (pid 5431) 0s
ok: run: nginx: (pid 5512) 0s
ok: run: node-exporter: (pid 5520) 1s

I have tried restarting the service by:

sudo gitlab-ctl restart but still not working

Any ideas?

Thanks.

ss -ntlp nginx

shows that nginx is bind and listening to port 80

This is confusing. Why only one user? Why reboot? And why https://192.168.1.50, that's a local address, no? Have you tried http://192.168.1.50 too? Port 80 is http, port 443 is https.
Are you saying your server works, but gitlab doesn't? Or something more spcific?

gitlab is hosted locally on our server behind vpn

currently one 1 developer is using it

gitlab-ctl reconfigure works fine

ufw status also shows ports are open

nginx is bind to port 80 using ss command not really sure what's going on

Thanks

That's for unencrypted traffic.
https://192.168.1.50/ is encrypted and defaults to port 443.

1 members found this post helpful.

I don't see an answer to this question.


JJJCR: What is the output of these commands (from outside the server):
Also, what do you get when you SSH onto the target server and run:

How was this determined and what does tail on the nginx log file(s) show?

Hi All, please see update below:


http://192.168.1.50 == no output nothing
https://192.168.1.50 == no output nothing
https://192.168.1.50:8060 == no output nothing

Yes nginx seems to be running, but Gitlab page is not showing up. No error also on the logs as well.

Thank you for your help.

Nope Gitlab is not working at all.

The nginx is the one that is built-in to Gitlab.

The server is fine, i am able to SSH.

The Gitlab page was showing up until I rebooted the system.

gitlab-ctl reconfigured seems to reconfigured fine no errors.

gitlab-ctl status shows all is running.

We're hoping that the 500 Internal Server Error will be resolved.

AFAIK, no change on the configuration was done so I rebooted the system, but then this issue happens. Gitlab page is not showing on the browser.

Next time, if you're going to reboot, just do the server software - aside from anything else, it should only take seconds not minutes.
(Also, a 500 error should be logging the reason for the error, so once you've got this issue resolved you might want to check into that.)

___

Ok, so Nginx/Gitlab responds locally on 192.168.0.50 port 80 but something is blocking ports 80 and 443 from outside the machine.

If a restart of the machine triggered the change in behaviour, it's unlikely to be a network firewall (unless someone happened to modify config at the same time - worth ruling out to be sure).

Assuming the rest of your security allows it, you could temporarily disable the firewall on that machine, repeat the external tests, then re-enable the firewall.

If that lets the requests through it confirms the issue as a firewall config one, if it doesn't something else is blocking the traffic.

1 members found this post helpful.

@boughtonp, @ondoho Thanks for your help guys.

What I did, installed GitLab on a VM and compare the settings on the prod one.

The newly installed GitLab on the VM works fine, so I followed the same settings on the prod one.

I just inherited the prod VM, I believe somebody had changed the settings already. Just saved it but never restarted the GitLab.

So, when the VM Prod server was rebooted then the issue appears.

Anyway, the local Github site is back and can be accessed via browser. But I am not sure though whether internal server error is resolved, will update once the developer gives a feedback.

I never knew about the curl command, it's quite helpful to troubleshoot. Thank you guys.

Marking this as resolved hopefully internal server error is gone as well.