Submitted 2 weeks ago by 
irmadlad@lemmy.world to selfhosted@lemmy.world
I was having some issues with Invidious the other day, which I resolved. However, I came across this tidbit of info that I’d never seen before when I first deployed it:
Post-install configuration: Highly recommended Because of various issues, Invidious must be restarted often, at least once a day, ideally every hour.
Anyone else observing this weird restart schedule?
I’d be surprised if most people running invidious for private use are following that advice. I’ve been on the master branch for a while and it gets updated fairly often. For my instance, I haven’t seen any reason to restart the service more often.
irmadlad@lemmy.world 2 weeks ago I haven’t seen any reason to restart the service more often.
Alright. Cool.
I stopped using Invidious a couple years ago, when I found out about FreeTube. I do have to update FreeT pretty often. I'll put Invidious back on my list. Thanks for bringing it back to my attention.
irmadlad@lemmy.world 2 weeks ago Thanks for bringing it back to my attention.
You’re welcome. I think they’ve made pretty decent strides especially with the companion app and the fact that YT is relentless in trying to circumvent frontends.
Seems like there's a FreeTube update every week or so. Cat and Mouse games, but what YT doesn't realize is that Invidious and Freetube are the Cats and YT is the mouse to be consumed.
That line predates invidious-companion. When the player and signature handling still lived in the main process, a periodic kick was the honest workaround, and the docs never really caught up after companion split it out.
What I’d push back on is the blind hourly restart, because it hides exactly the failure you just had. A companion image sitting a version behind shows up as things half-working, and a scheduled restart makes that go away for an hour at a time, so you never trace it. If you’re going to script something, script a check instead: hit an endpoint that actually plays a video, restart only when that fails, and log it when it does. Then a restart tells you something happened.
Small thing that would have caught your case: docker compose pull with no service name pulls all three, and docker compose images prints the digests you’re actually running.
irmadlad@lemmy.world 2 weeks ago That makes sense. I’ll see what I can come up with. Thanks for the guidance.
Here’s the shape, if it saves you the fiddling. Put it in the compose file rather than a cron:
healthcheck: test: ["CMD-SHELL", "wget -qO- http://localhost:3000/api/v1/trending >/dev/null || exit 1"] interval: 5m timeout: 10s retries: 3 restart: unless-stopped
Port and path to match your setup, and use wget rather than curl unless you know the image ships curl, since a healthcheck that fails because the binary is missing looks exactly like a service that is down.
One catch: Docker marks a container unhealthy but won’t restart it for you. Either pair it with something like autoheal, which watches for that state, or keep your cron and have it check first and restart only on failure.
Either way you get the thing the blind hourly restart can’t give you: a log of how often it actually fired. Never, and you didn’t need the restarts. Constantly, and there’s a real bug worth chasing rather than a schedule papering over it.
mike_wooskey@lemmy.thewooskeys.com 2 weeks ago I haven’t had to adjust or look at my invidious instance configs in a long time, but I do remember that in their docker instructions and I think I configured my container to restart hourly (or maybe I made it every other hour? Daily?). I’ve had no problems with my invidious instance in a long time, but that may have nothing to do with frequent restarts.
irmadlad@lemmy.world 2 weeks ago I think thats what I’ll do. Write a script, fired by a cron, to restart all three containers hourly and see how that goes. As I said further down, or up where ever this comment lands, that I do, on rare occasions, have issues with it. So, restarting couldn’t really hurt I wouldn’t think.
TeaWithDani@lemmy.world 2 weeks ago
I haven’t used this tool specifically, but anything involving Youtube is always going to be an uphill battle. In the instance of a video downloader like Channeltube, you frequently need to feed it fresh cookies to make sure Youtube doesn’t flag it as a bot. I assume this is a similar situation.
The requirements also list ‘‘2gb if you restart frequently’’ so there might be a memory leak issue, or the way it’s setup means the RAM usage will increase in perpetuity.
I would just script a task to restart the docker container every hour. Shouldn’t be too much a hassle. I would track its RAM usage over a few days too. See if there’s something fishy happening. Something like Beszel will let you track your docker socket, so usage per container. Preferably left on read only imo.
Yeah, I was thinking about that. A script fired by a cron every hour. I do have the occasional, rare issue with Invidious. So, I’m wondering if indeed I need more restarts. It couldn’t hurt.
TeaWithDani@lemmy.world 2 weeks ago
What kind of issues have you had? How did you resolve them?