Licenses and changing servers

Hello,

I am going to be moving our synced git repositories to another server. I just want to confirm a few things before starting:

  • For subgit licensing, so long as I shut down all the subgit daemons running on the old server, I won’t have any issues with starting them on the new server and I can use the same license key
  • I will be taking gitlab hosted repos and moving them off gitlab. The only change I can make is directory = custom_hooks setting and move my hooks into the hooks directory. Do I need to run 'subgit installafter modifying this setting or will restarting withfetch --async` be sufficient?
  • Do I need to re-run subgit register on the new server after moving the repositories? In general, everything is installed in the bare repository itself so copying it entirely is sufficient to take along all subgit state/data?

Thanks
Jonah

Hello Jonah,

  • yes, that’s correct, you can use the same license key after moving all the repositories from the old server to a new one;
  • if all the changes are made manually (hooks are moved and the config is changed) then the fetch should be enough; I would rather recommend running subgit install instead, SubGit will apply all the changes and place all the hooks to an appropriate directory;
  • actually, SubGit stores the metadata not in the repositories themselves, so moving the repositories only won’t bring the registering metadata and thus it will be required to run subgit register for those repositories.

Hi Ildar,

It looks like I am able to move the repository, however, when I try to move the subgit hooks from custom_hooks I get an error

remote: TEMPORARY ERROR:
remote:         Failed to launch background translation process: timeout waiting for pid file '/var/www/git/qa-infra-prototypes/mainline.git/./subgit/daemon.pid'.
remote: 
remote: CURRENT STATE:
remote:         Both Git and Subversion repository are open for pushes or commits.
remote:         Your commit was not committed, but you may retry it.
remote: 
remote: TO RECOVER:
remote:           A) Address the problem if possible and then retry commit
remote:         OR
remote:           B) Run on the server
remote:              $ subgit uninstall /var/www/git/qa-infra-prototypes/mainline.git/.

After which the daemon appears to have died. This happens if I try to manually change the hooks directory. subgit does not detect the change and move the hooks if I run ‘subgit install’.

I tried running uninstall and install again as the error message suggests but no luck. Good news is it’s not blocking since I can leave the hooks where they are but it looks like something is wrong.

The logs show:

[2021-09-24 11:25:25.855][pre-receive] Waiting for pid file '/var/www/git/qa-infra-prototypes/mainline.git/./subgit/daemon.pid' creation.
[2021-09-24 11:25:37.355][pre-receive] Failed to launch background translation process: timeout waiting for pid file '/var/www/git/qa-infra-prototypes/mainline.git/./subgit/daemon.pid'.
[2021-09-24 11:25:37.355][pre-receive]   at launch_daemon (daemon.c:226)
[2021-09-24 11:25:37.355][pre-receive]   at open_connection (daemon.c:359)
[2021-09-24 11:25:37.355][pre-receive]   at hook_daemon_client_send_packet (daemon.c:460)
[2021-09-24 11:25:37.355][pre-receive]   at hook_execute (hook.c:284)
[2021-09-24 11:25:37.355][pre-receive]   at internal_pre_receive (pre-receive.c:225)
[2021-09-24 11:25:37.355][pre-receive]

When I moved the hooks back and reverted the config the error disappeared.

Hi Jonah,

the timeout waiting for pid file error usually appears due to problems accessing the file or due to slow daemon start, it’s pretty strange that this error appear in this case.
As for the hooks moving – this definitely should work if the hooks themselves are moved to the new directory (say, the hooks directory) and the hooks.directory setting in the config file is set to point ti the new directory. I have just tested it once again moving a repository from GitLab to another machine and it worked just fine. I may suppose that the issue could happened due to incorrect files permissions, both read/write access (especially for the pid file) and the executable bit for the hooks, could it be the case?

ok I think I found the issue. I am running the git server from inside a docker container wuith a mounted directory but running subgit on the host machine.

[2021-10-06 14:20:49.780][pre-receive] Failed to delete pid file '/var/www/git/qa-infra-prototypes/mainline.git/./subgit/daemon.pid', it doesn't exist

The var/www... path is the path on the container, not on the host. What’s weird is that subgit isn’t even installed in the container, how is it picking up the container path? The path on the host is /srv/git-server/repos/qa-infra...

I’d prefer to keep this setup without moving subgit into the container. is there a way to resolve this?

Hi Jonah,

we don’t recommend such a setup with SubGit and Git server running on different machines, including cases when SubGit on a host while Git server in a container; and the issue you faced with is the exact reason why we don’t recommend it. The matter is that the hooks starts inside the container (and that’s where it gets the path from) while the daemon is running on the host and they are not aware of each other. SubGit is not supposed to have its processes distributed across different machines, it expects they are in the same environment and can interact directly, so it acts incorrectly in such a setup. And that is the reason why in case of using containers we always recommend to put SubGit inside the container where a Git server runs. I’m afraid there is no way to resolve the issue while SubGit and GitLab are not in the same container, the only workaround is that approach you already got – I mean, it’s possible to remove or otherwise disable hooks in the repository, so that SubGit hooks is not invoked during the push. It will disable the synchronization during the push operation, so that the changes will not be synced immediately, but will be picked up by periodic synchronization that the daemon runs. That, in turn, may lead to conflicts if a new commit comes to SVN while a new Git commit exists on Git side; but on the other hand, this approach allows to have SubGit and GitLab not on the same machine.

ok that mystery is finally solved :P

Moved subgit into the container and all appears to be well again. thanks Ildar!

Great! Glad to know it works now :)