git2consul problem does not cause Docker container to exit
boarder981 opened this issue · 4 comments
Please note that I'm using the dockerized version of git2consul, latest tag 0.12.13. I'm posting here because activity in the docker project looks pretty slim.
Occasionally git2consul appears to "die" inside the container and logs stop streaming/writing to file, however the container keeps running. Restarting the git2consul container usually fixes the issue. Ideally the container would exit so that I could use a Docker restart policy to restart it automatically, but in this case that option is useless.
Has anyone experienced this? I'm not sure of the root cause, and even with log level set to "debug", it doesn't appear to output any warnings or errors. In fact, I don't ever see errors, so is there a higher log level than debug?
In any case, here is a snippet of my config:
{
"version": "1.0",
"max_sockets": 10,
"expand_keys_diff": true,
"local_store": "/tmp/git2consul_cache",
"logger" : {
"name" : "git2consul",
"streams" : [{
"level": "trace",
"stream": "process.stdout"
},
{
"level": "debug",
"type": "rotating-file",
"path": "/tmp/git2consul.log"
}]
},
"repos" : [
{
"name" : "project-1",
"url" : "git@git.company.com:path/to/project-1.git",
"include_branch_name" : true,
"source_root": "consul-kv",
"mountpoint": "dir",
"support_tags" : true,
"branches" : ["master"],
"hooks": [
{
"type" : "polling",
"interval" : "1"
}
]
},
{
"name" : "project-2",
...
Any insight or suggestions would be greatly appreciated!
+1
+1
Anyone have thoughts or ideas on how to fix this?
Just FYI - since I submitted the original post, I changed the polling interval for all of my projects to 5m instead of 1m. I thought perhaps maybe it was pulling too many things and was overlapping on itself. In any case, this seemed to stabilize the environment a bit, but we're running into the same issues again.
Looking at the number of open PRs, issues etc and lack of releases since 2016, I'd venture to say this project is abandoned
In the meantime, seems it has something to do w/ the sheer number of repositories and tags/branch combinations you are dealing with.
Perhaps the solution is just to run multiple git2consul instances, have each one limited and responsible for only N repositories, when you reach that ceiling, dedicate a separate git2consul instance for handling another bucket of N repositories