5
nitwhiz
5y

Can anyfuck tell me what the fuck I'm supposed to do?

So I installed gitlab, reachable under a subdomain (gitlab.example.com) behind apache2. everything works fine.

Now I see this bullshit in my logs, appearing EVERY GODFORSAKEN SECOND: https://gist.github.com/nitwhiz/...

I disabled the bundled nginx in the gitlab.rb and no, it's not "some nginx system service", I verified it is coming from gitlab and oh - btw - some weird svc logfuck runs even after gitlab is stopped! :)

No I won't try your random google result because I read all 3 tickets being at least half relevant to my situation as ANYFUCKER ON THIS PLANET seems to use the internal nginx.

FML.

Comments
  • 4
    Oh come on...

    ´netstat -ntlpa | egrep ":(443|80) "´
    ´lsof -i :443; lsof -i :80´
  • 1
    @netikras before being so cocky maybe read that i very well know that Apache is running on 80 and 443, running multiple vhosts, including the one for gitlab. As it should.
  • 0
    @theKarlisK but why does it even try to bind this bundled nginx if it is disabled?
  • 0
    @nitwhiz Noob question, did you make sure it is not auto starting nginx again? Or ignoring your settings?
  • 0
    @nitwhiz audit, strace

    But apparently I am too cocky (and too blind as I still don't see all this info in your post) to elaborate :)
  • 1
    @gitpush settings aren't ignored, it picks all other ones up.
    Why does it autostart is the question.:/
  • 0
    @netikras huh? "Gitlab behind apache2, everything works fine." Of course apache listens on 80 and 443?
    Nginx should not even run and try to bind port 80 or 443. It comes bundled with gitlab but i have multiple vhosts already set up and thus disabled the internal nginx. Still gitlab starts it, that's the problem.
  • 1
    @nitwhiz Not sure what you tried already, but did you check this: https://docs.gitlab.com/omnibus/... (look for disable bundled nginx)
  • 0
    @gitpush did exactly this, yeah.
    On reconfig the disable nginx section takes a little (3-4 secs) but signals me everything went well.
  • 0
    @nitwhiz I'm out of options, good luck getting that fixed :)
  • 1
    @nitwhiz "Of course apache listens on 80 and 443" <-- how should I know your apache configuration?

    As I've already mentioned, try audit. It'll show which processes are writing to your log file and which processes are trying to bind to your mentioned ports.
  • 0
    @netikras that audit tip is good but i know the pids already.

    The process is the integrated nginx from gitlab. I don't know what it is for but it restarts when i kill it even tho gitlab is not running.
  • 1
    @nitwhiz That's obvious, there is a check'n'respawn mechanism in place to maintain service availability.

    https://superuser.com/questions/...

    you'll find what's respawnng it (assuming you don't already see PPID, i.e. the nginx is daemonised).

    If there's a watchdog process respawning nginx -- just nuke it as a PoC. Else -- you'll have to dig into gitlab's configurations

    Also, auditd will help you figure out what's spawning that 'svc logfuck', whatever you meant by it.
  • 0
    so I got this shit sorted now. turns out if you enable the whole letsencrypt shit integrated in gitlab, it uses it's internal nginx to do so.

    actually I can see why but holy shit this was an unnecessary ride.
Add Comment