Skip to content

Time out waiting for logrotate socket to appear

I constantly run into a stuck ruby_block[wait for logrotate service socket] message when installing GitLab within a Docker container. This has been described in #4257 (closed) .

The workaround of running runsvdir-start works:

/opt/gitlab/embedded/bin/runsvdir-start &

However, it seems that the the wait_for_service in https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/775e3e77bbcc7bb9dd57f8bd5cd8bea3ae96b1a5/files/gitlab-cookbooks/runit/libraries/provider_runit_service.rb#L307 spins indefinitely.

From https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/6abcc78b3990bdeecd1d5e7ff2261780709aafeb/files/gitlab-cookbooks/runit/libraries/helpers.rb#L55-63:

    def wait_for_service
      raise 'Runit does not appear to be installed. Include runit::default before using the resource!' unless binary_exists?

      sleep 1 until ::FileTest.pipe?(::File.join(service_dir_name, 'supervise', 'ok'))

      if new_resource.log
        sleep 1 until ::FileTest.pipe?(::File.join(service_dir_name, 'log', 'supervise', 'ok'))
      end
    end

I have some suggestions on how to improve this:

  1. Time out after some time (1 minute?).
  2. Can we check if runsvdir is even running? I don't think runsvdir writes out a PID file, but perhaps we can run pidof or even systemctl status.
  3. Just add documentation after the timeout saying, "You may need to start runsvdir via /opt/gitlab/embedded/bin/runsvdir-start".
Edited by Stan Hu