gitlab-runsvdir.service not enabled running on CentOS 7

[gwarf]

Hi,
Using vshn/gitlab v1.5.0 on CentOS 7 with gitlab-ce 7.14.1 omnibus package it seems that the gitlab-runsvdir systemd service is not running, and /usr/bin/gitlab-ctl seems not able to start the gitlab services without having it running. As gitlab-runsvdir systemd service is not enabled gitlab also does not start automatically on boot.

root@sources ~ # /usr/bin/gitlab-ctl status
fail: ci-redis: runsv not running
fail: ci-sidekiq: runsv not running
fail: ci-unicorn: runsv not running
fail: logrotate: runsv not running
fail: nginx: runsv not running
fail: postgresql: runsv not running
fail: redis: runsv not running
fail: sidekiq: runsv not running
fail: unicorn: runsv not running
root@sources ~ # /usr/bin/gitlab-ctl start
fail: ci-redis: runsv not running
fail: ci-sidekiq: runsv not running
fail: ci-unicorn: runsv not running
fail: logrotate: runsv not running
fail: nginx: runsv not running
fail: postgresql: runsv not running
fail: redis: runsv not running
fail: sidekiq: runsv not running
fail: unicorn: runsv not running
root@sources ~ # systemctl status gitlab-runsvdir.service                                                                                                      
gitlab-runsvdir.service - GitLab Runit supervision process
   Loaded: loaded (/usr/lib/systemd/system/gitlab-runsvdir.service; disabled)
   Active: inactive (dead)

root@sources ~ # systemctl enable gitlab-runsvdir.service                                                                                                      
ln -s '/usr/lib/systemd/system/gitlab-runsvdir.service' '/etc/systemd/system/basic.target.wants/gitlab-runsvdir.service'
root@sources ~ # /usr/bin/gitlab-ctl start                                                                                                                     
fail: ci-redis: runsv not running
fail: ci-sidekiq: runsv not running
fail: ci-unicorn: runsv not running
fail: logrotate: runsv not running
fail: nginx: runsv not running
fail: postgresql: runsv not running
fail: redis: runsv not running
fail: sidekiq: runsv not running
fail: unicorn: runsv not running
root@sources ~ # systemctl start gitlab-runsvdir.service                                                                                                       
root@sources ~ # /usr/bin/gitlab-ctl status                                                                                                                    
run: ci-redis: (pid 1533) 4s; run: log: (pid 1530) 4s
run: ci-sidekiq: (pid 1537) 4s; run: log: (pid 1534) 4s
run: ci-unicorn: (pid 1547) 4s; run: log: (pid 1541) 4s
run: logrotate: (pid 1544) 4s; run: log: (pid 1539) 4s
run: nginx: (pid 1536) 4s; run: log: (pid 1532) 4s
run: postgresql: (pid 1545) 4s; run: log: (pid 1542) 4s
run: redis: (pid 1535) 4s; run: log: (pid 1531) 4s
run: sidekiq: (pid 1540) 4s; run: log: (pid 1538) 4s
run: unicorn: (pid 1546) 4s; run: log: (pid 1543) 4s

It looks like that the service is explicitely disabled in manifest/params.pp and is using custom start/stop commands directly calling /usr/bin/gitlab-ctl that seems not to be working without the systemd service, is this the expected result am I the only having a problem with this configuration?

Enabling and starting the service manually does fix the problems, gitlab-ctl will be able to restart the services and gitlab will run on boot as expected.

Best,
Baptiste

[tobru]

Hum, I'm not a Centos/systemd specialist. So maybe someone who knows this to systems should have a deeper look into it... It could probably help to set $service_enable to true. Did you try that?

[gwarf]

Yes I did set it, at least it allows the service to be started on next boot/reboots, but it does not start it.
I did not test on a fresh/clean VM directly with gitlab-ce 7.14.1, so I don't know if it can be related to an update of gitlab's chef recipes, gitlab-runsvdir systemd service or gitlab-ctl.

[cdenneen]

+1 same issue with 7.14.3

[mat1010]

I'm using version 1.6.0 of vshn/puppet-gitlaband gitlab 8.1.3-ce on Centos 7. By default the service is not enabled - since it's set to false in the params.pp.

But setting it to true works like expected - even after reboots.

[tobru]

closed by #43