1.11.x does not listen on port

[PaulBINK]

• Gitea version (or commit ref): 1.10.1, 1.11.3, 1.11.4
• Git version: 2.7.4 (server)
• Operating system: Ubuntu 16.04.6 LTS
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

Just as with issue #10644, gitea will not listen on a port to accept connections. This was after an upgrade from 10.0.1. Waiting did not help. Rebooting did not help either.

I started gitea manually (gitea web), and there are no errors or warnings shown. There's also nothing in particular in the log. It starts up fine, it just won't be listening to any connections. netstat does not show gitea either. Trying a git pull through SSH also fails.

Restoring the previous version works right away, and it does show up in netstat.

I haven't found anything about settings having changed. Has there been a change in networking in Go, Macaron or Gitea you know about that could cause this kind of problem? Maybe settings that do work with 1.10.1 no longer work with 1.11.x? Could it be Linux version related? It's a really bad time to try a Linux upgrade on a remote virtual machine.

I'll try to test it in isolation tomorrow (separate process, different port, different versions). Anything else to try?

[guillep2k]

You're probably under SELinux. If you've used port labeling to allow Gitea to open a restricted port when you installed the first instance, you'll need to use it again every time you change the executable, since port labeling works by the executable signature and not by its path or permissions. That's also why restoring the previous versions would make it work again.

[PaulBINK]

Nope, not port labeling, but thanks for the suggestion. I'm using Ubuntu and I've already performed 13 successful updates since version 1.3.3 (over 2 years ago) up to 1.10.1 (last december) without a hitch. 1.11.3 is the first version ever to give issues. That's why I wonder what could have changed in the last few months that could cause this behaviour.

[zeripath]

We need to see some logs.

[PaulBINK]

Strange. When I looked at the log in the server itself I couldn't find anything in particular. Now I have it open on my own machine, and now I see what's the problem: the location of the certificate.

It's trying to load it from custom/, but it's located in the root map. In app.ini it's a relative path: ssl/name.crt. The change was then the base map used to look up for the certificate. A link should solve this, but it's now too late to start messing up with the server. I'll try again tomorrow. Any other base map changes I should be aware of?

[mrsdizzie]

Sorry, this is a breaking change for SSL cert paths as of 1.11 described in the Changelog here:

https://blog.gitea.io/2020/02/gitea-1.11.0-is-released/#1-11-0

"Make CertFile and KeyFile relative to CustomPath (#9868) (#9874)"

Theres no other changes like that (this was just the SSL path not behaving as it should have before). Would probably just recommend using full paths always to 100% avoid any ambiguity.