Closed tias77 closed 4 years ago
Hi! We're currently reviewing this issue.
So, this only happens when --server.address
is an IPv6? I've been testing on an Alpine VM (just to check if the issue it's also there) but there's no error (at least for now).
Hi
Yes, my interpretation was that as soon as i added an IPv6 address to --server.address
the validation process never ended. I have now tried it with a clean cache and without any tal, and it finishes as expected and accepts RTR connections on both IPv4 and IPv6.
I have also tried it with each tal by itself, and it works fine.
When I add all five of them it doesn't finish validating, even after 30min waiting with cpu idling.
The ipv6 thinking was probably just a 'red herring' as it does not seem to come alive now even without --server.address
Investigation continues
Yeap, same here, after several test this has happened only when using the 5 TALs.
Looking into the container, I've noticed that beside the main process, sometimes there are a couple of child processes alive and doing nothing. This might be due to a fork that we do to execute rsync, but something it's happening that the child processes don't exit in some (still unknown) cases.
I'm still reviewing this, hopefully I'll expect to find what's going on to fix it.
The related commit comment describes what's happening and how it's fixed.
The fix will be included in the upcoming version: 1.3.0, currently at QA. This version will be released soon, once our QA team approves it.
Gotta say, this issue it's quite peculiar, since we've only seen it in docker + alpine images, so thanks for this issue report :smiley:
v1.2.1 in docker/alpine on debian10
Normal startup:
If started with --server.address it never leaves
I want fort to accept RTR sessions on both IPv4 and IPv6 sockets, by default it only accepts IPv4 sessions.