-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add healthcheck for go2rtc service #5545
Add healthcheck for go2rtc service #5545
Conversation
Also don't make go2rtc exits cause the container to fail.
✅ Deploy Preview for frigate-docs canceled.
|
Co-authored-by: Nicolas Mowen <[email protected]>
Co-authored-by: Nicolas Mowen <[email protected]>
For some reason this new service isn't even starting for me. I'm trying to debug what's happening. |
@NickM-27, we can probably speed up the go2rtc initialization if we only create the config once. For that, I'd create the config in /dev/shm, and on next initializations I'd check if the config exists already and if it does, use it rather than recreate it. What do you think? |
Yeah I think that makes sense |
Ok, so this is working. If I copy and paste the healthcheck's run contents to frigate's run contents, it works great. However, s6 is not starting the go2rtc-healthcheck service itself and I really don't understand why. This should be the only missing thing. |
do you need to add the |
I'm checking here. Another thing, since go2rtc is now allowed to restart, we need to be more careful during initialization: If go2rtc config for example is invalid, go2rtc will keep restarting forever. We should handle this case and make the container exit, I think. Or maybe not? |
I think we should definitely fail if the create_config.py errors out, but if go2rtc doesn't like the config then that is something the create_config.py script should handle to ensure we only provide go2rtc with a valid config. |
I don't think this is possible, because the create_config.py will pass whatever the user has set directly to go2rtc. Which may be a valid YAML but not a valid config. i.e. we need to invoke go2rtc |
That fixed the issue, but I think this is probably a bug of s6-overlay. I should probably report it :( |
actually I don't think it will be an issue. If the frigate config contains invalid yaml then frigate itself will not keep running. Personally, I think if the user provides an invalid config it is okay. It may change in the future but for now I believe go2rtc does not actually do yaml validation. For example, if you add
it should be |
Not that I know s6 super well but I think it makes sense that it would be required. all the other ones seem to require producer-for or consumer-for |
Only because they make use of s6's logging services. I was not trying to integrate the healthcheck with the logging service, but it turns out to be a nice thing. Now the logs from both go2rtc and the healthcheck are merged and can be seen from Frigate UI. Also, some initialization logs were being hidden and they are now part of the logs that can be seen from Frigate UI. |
Ok, let's revisit this later if we find a need then. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Been running this for a few minutes and all seems well, the logging improvements are nice as it should give some more info as well
Maybe we can decrease the time window to 30s? |
I think that would be fine, I definitely wouldn't go lower than that though. Curious what @blakeblackshear thinks |
30s seems fine. I don't see any reason this would add significant overhead. |
Also: