Redirect loop when downloading archive.zip

My gitlab ce instance (7.12.0, built from source) does not want to let me download a zip archive of a repository.

I’ve seen https://gitlab.com/gitlab-org/gitlab-ce/issues/1565 and I have -q archive_repo in my sidekiq service definition, and ps aux shows that sidekiq gets indeeed started with the param, but I still get the redirect loop.

repository_downloads_path is set to tmp/repositories, the folder exists (created it by hand) and has permissions set correctly, as far as I can tell (owner gitlab user, group gitlab user and drwxrwxrwx, just to make sure).
I’m trying it with a really small repo (just one image and a README.md) to rule out any nginx size misconfigs at this point. nginx is set to client_max_body_size 1G, so that shouldn’t be a problem either.

When attempting to download an archive, my sidekiq.log (with SIDEKIQ_LOG_ARGUMENTS=1) tells me:

2015-07-01T07:12:37.032Z 26663 TID-hi5g4 RepositoryArchiveWorker JID-d8aa14cc9ff5d35cea1e1079 INFO: start
2015-07-01T07:12:37.032Z 26663 TID-hi5g4 RepositoryArchiveWorker JID-d8aa14cc9ff5d35cea1e1079 INFO: arguments: [26, nil, “zip”]
2015-07-01T07:12:37.193Z 26663 TID-hi5g4 RepositoryArchiveWorker JID-d8aa14cc9ff5d35cea1e1079 INFO: done: 0.161 sec

and then the same for quite a lot more workers.

The only other thing I can see is in unicorn.stderr.log:

I, [2015-07-01T00:45:15.314576 #20145] INFO – : worker=0 ready
W, [2015-07-01T03:14:32.431291 #2976] WARN – : #Unicorn::HttpServer:0x00000002d4f2b8: worker (pid: 2976) exceeds memory limit (240340992 bytes > 238607705 bytes)
W, [2015-07-01T03:14:32.431380 #2976] WARN – : Unicorn::WorkerKiller send SIGQUIT (pid: 2976) alive: 23284 sec (trial 1)

This doesn’t directly correspond to created workers from sidekiq.log, though.

And it goes on and on. Additionally, I get the same behaviour with another instance that’s still running 7.11.3.
I’ve already commented on the issue mentioned above, before I knew about this forum, but I’m not really positive it’s a gitlab issue per se, but I’m out of ideas.

And ideas what I’m doing wrong?

Getting the same here.

Just updated to 7.13.1. Problem still persists. Exactly the same behaviour as before.

I have encountered the infinite redirect as well when downloading archives of the repositories.

Just for reference I use arch linux and update gitlab continously.

Make sure to use the updated systemd files, there was an option missing which caused redirect loops. See https://gitlab.com/gitlab-org/gitlab-recipes/commit/cb39ca2c1fd631a223a16d160b9596e307a96052

Interestingly the systemd service used by the AUR package already contains the entry -q archive_repo for quite some time. The service file may be custom made.

If I were proficient enough with gitlab’s infrastructure and sidekiq, I would try to fix this but as it stands I would spend many hours with little gain.

Yep, the arch systemd file contains -q archive_repo. The Gitlab Dashboard shows that sidekiq has picked up the queue, too. Unless the position of -q archive_repo matters, everything is as it should be.

Here’s what the default arch systemd file for sidekiq looks like:

    [root@git ~]# cat /etc/systemd/system/gitlab.target.wants/gitlab-sidekiq.service 
    [Unit]
    Description=GitLab Sidekiq Worker
    Requires=redis.service
    Wants=mysqld.service postgresql.service
    After=redis.service mysqld.service postgresql.service network.target

    [Service]
    User=gitlab
    Group=gitlab
    WorkingDirectory=/usr/share/webapps/gitlab
    Environment=RAILS_ENV=production
    SyslogIdentifier=gitlab-sidekiq

    CapabilityBoundingSet=
    PrivateTmp=true
    PrivateDevices=true
    ProtectSystem=full
    ProtectHome=true
    # NoNewPrivileges breaks gitlabs' email delivery if you
    # use postfix' sendmail wrapper. If you use an SMTP server
    # instead you can safely enable this security feature.
    #NoNewPrivileges=true

    ExecStart=/usr/bin/bundle exec "sidekiq -q post_receive -q mailer -q system_hook -q project_web_hook -q gitlab_shell -q common -q default -q archive_repo -e production -L /var/log/gitlab/sidekiq.log >> /var/log/gitlab/sidekiq.log 2>&1"

    [Install]
    WantedBy=multi-user.target

I’m running this proxied by nginx, btw. I can post the nginx config too, if it helps.

Got one server on 8.1 now, another one on 8.0.3. Problem still persists.

Anyone got an update on the issue?

I asked over on the original issue, too.
For reference: https://gitlab.com/gitlab-org/gitlab-ce/issues/1565

For me 8.2.1 fixed this.