Skip to content

GitLab

Closed
Created by Administrator@rootOwner

Unable to Save Public Key with Large Number of Repos

Created by: mutewinter

With a large number of repos (> 100), saving a pubic key fails. This is due to the timeout in the Gitlabhq::Gitolite.configure method being too short.

Here's the responsible code

def configure
      status = Timeout::timeout(20) do
        File.open(File.join(Dir.tmpdir,"gitlabhq-gitolite.lock"), "w+") do |f|
          begin 
            f.flock(File::LOCK_EX)
            pull
            yield(self)
            push
          ensure
            f.flock(File::LOCK_UN)
          end
        end
      end
    rescue Exception => ex
      raise Gitolite::AccessDenied.new("gitolite timeout")
    end

The problem is that this fails silently because the Gitolite error page is returned to the POST request initiated by JavaScript. Here's the error returned from the POST at /keys

<!DOCTYPE html>
<html>
<head>
  <title>We're sorry, but we cant get access to your gitosis</title>
  <style type="text/css">
    body { background-color: #EAEAEA; color: #666; text-align: center; font-family: arial, sans-serif; }
    div.dialog {
      width: 600px;
      padding: 0 4em;
      margin: 4em auto 0 auto;
    }
    h1 { font-size: 48px; color: #444; line-height: 1.5em; }
    h2 { font-size: 24px; color: #666; line-height: 1.5em; }
  </style>
</head>

<body>
  <!-- This file lives in public/500.html -->
  <div class="dialog">
    <h1>Gitolite Error</h1>
    <h2>We're sorry, but we cant get access to your gitolite system.</h2>
    <h3> 1. Check 'config/gitlab.yml' for correct settings.</h3>
    <h3> 2. Be sure web server user has access to gitolite.</h3>
  </div>
</body>
</html>

This error message is only visible when running Chrome Developer Tools with the Network tab loaded. Selecting the POST request after the 20 second timeout displays the above error html.

The temporary solution to this problem is to increase the timeout to allow for the update_project method to finish being called for all 200 projects. The long term solution would be some sort of background job system so that the updates take place off the web request thread.