Notice: Often only works after container restarts

[Sommerwiesel]

This is not a bug but something I noticed during the past days.
On my server, the rotation (and therefore the unblocking) only really takes effect after a container restart.
So, simply running the ipv6rotator will not (immediately) unblock the instance.
When I run ipv6rotate (my wrapper for /srv/ipv6rotate/smart-ipv6-rotator.py run --ipv6range=***) the blocking persists.
However, as soon as one of the instances restarts (during the hourly restart cron) it is unblocked.
And if i manually run ipv6rotate && systemctl restart invidious@web.service all of them restart and are unblocked.

@unixfox Do you have some advice whats the best practise at this point?
Should I just cron ipv6rotate and the restart of ALL containers hourly, together?

[unixfox]

That is not normal, ipv6 routes should be reflected immediately. I have a feeling that something else related to invidious is acting up.

I have merged a PR that should help in youtube thinking that invidious is up to date now: iv-org/invidious#4473. Please check if it helps.

[Sommerwiesel]

Is the PR already in 2024.03.08-99a5e9c?
If yes, didn't help.

I'm gonna change the hourly cron to do the ipv6rotate as well as restarting all containers for now, as a temporary hotfix.

[unixfox]

Yes it's in the latest commit so 99a5e9c.

I can somewhat reproduce the issue on my end and I'm using kubernetes so this is different from a normal docker-compose install.

For now I do not have the free time to investigate the issue so I have also changed the restart of invidious to hourly restart.

[unixfox]

Note to self: I have a feeling that it's related to some kind of "keepalive" HTTP in invidious that keeps the connection to YouTube servers: https://stackoverflow.com/questions/20763999/explain-http-keep-alive-mechanism

Maybe we should try to see if we can disable this functionality in the HTTP client and see if it's better.