Connection refused to daemon

SubGit
#1

We are running subgit on gitlab to mirror our subversion repos to git. (Read only at the moment)

After restarting the gitlab docker I run a script to sync all repositories but sometimes some of the syncs fail with the following message

SubGit version 3.3.6 ('Bobique') build #4276

Scheduling sync... error: Failed to open connection to the daemon 'pid=1311; port=40031; address=127:0:0:1; user=git'.
error: Connection refused (Connection refused)
error: Unexpected error has occurred; please report along with the logs ('/var/opt/gitlab/git-data/repositories/mikado/subgit-fetch-20191128-123259.zip')
error:   to http://issues.tmatesoft.com/, thank you!

I run gitlab + subgit as docker using marq/gitlab-ce-subgit:latest from here https://hub.docker.com/r/marq/gitlab-ce-subgit or https://github.com/cmarquardt/docker-gitlab-ce-subgit

the script to sync is as follows

#! /bin/bash

echo "enabling sync"

for REPO in core hello.world hello.back extension documentation
do
echo "Repo: ${REPO}"
subgit fetch --async ${REPO}.git
sleep 10
done

Which of the repos sync successfully and which fail is somewhat consistent as long as I don’t change anything but random over docker updates etc

#2

Hello Simon,

this may happen due to asynchronous fetch start, the daemon may still running. As a workaround try to change the script removing the --async option. Also, it would worth to set daemon.idleTimeout to 0 in the SubGit configuration file:

[daemon]
    idleTimeout = 0

If it doesn’t help describe your setup and circumstances in a little more detail: do I understand correctly you run this Gitlab docker container on Linux host? Is that script is a startup script to trigger the mirroring or you run it otherwise? Did I understand correctly that the issue happens in the same repositories all the times, but the affected repositories set changes with docker container updates?

#3

Hello Ildar,

If I remove the --async option, will it sync only once or continuously? We run this script manually once after rebooting our Gitlab docker container on Linux but the intention is to automate this as a startup script.

I removed the --async part but it still fails for two out of eleven repos with the same error message. I then ran the script again and the same two repos failed to sync again. The first one that fails is our biggest one (but still only 4k commits)

I now looked at htop and see about 22 java instances of subgit looking at only two repos? each consumes about 600mb of ram

Thanks a lot
Simon

#4

Hello Simon,

The --async option only tells SubGit not to block execution, but the command itself will only run once, not continuously. As for the test – could you advise please have you changed the daemon.idleTimeout setting as well? Judging from that you have 22 Java processes, it appears that this settings hasn’t been changes, could you please try it, too?

#5

Hello Ildar,

I set daemon.idleTimeout in the subgit/config file of each git repository but there still seem to be long-running processes:

ps -eo cmd | grep subgit
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -noverify -client -Djava.awt.headless=true -Djna.nosys=true -Dsvnkit.http.methods=Digest,Basic,NTLM,Negotiate -cp /var/opt/gitlab/git-data/repositories/mikado/assistant.git/subgit/lib/subgit-3.3.5_4042_fat.jar org.tmatesoft.translator.SubGitDaemon --svn /var/opt/gitlab/git-data/repositories/mikado/assistant.git --limit 1575874825387
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -noverify -client -Djava.awt.headless=true -Djna.nosys=true -Dsvnkit.http.methods=Digest,Basic,NTLM,Negotiate -cp /var/opt/gitlab/git-data/repositories/mikado/documentation.git/subgit/lib/subgit-3.3.6_4276_fat.jar org.tmatesoft.translator.SubGitDaemon --svn /var/opt/gitlab/git-data/repositories/mikado/documentation.git --limit 1575874850127

(I reduced the script to sync only the first three repos for testing)

One repo still fails with no difference to before.

If async does not mean it runs automatically in background, do I actually need a cron job to keep git synced to svn changes?

Thanks a lot
Simon

#6

Hello Simon,
could you advise please, have you run ‘subgit install’ against the repositories to apply the setting? If not, it might happen that it wasn’t applied and thus inactive. If the setting was applied but the daemon process is still there, please collect logs from those repositories (assistant.git and documentation.git) and also from the failing one.