Fix potential NGINX static file permission errors #150
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for looking at this. I have also been trying to solve these issues, and will continue to look at it next week. I tried your master branch, but still seem to be experiencing the same problems. Whenever I run the survey_700_band_iq action (on my system with MOCK_RADIO=1 and MOCK_RADIO_RANDOM=1), I can see the log messages for 705, 709, 731.5, and 739 MHz acquisitions. Then appears that the worker dies and a new worker is created. I also tried disabling the healthcheck and removing the autoheal container, but the same problem still occurs. Log messages are below: |
|
I also continue to get the below error with the current scos-sensor master branch and your master branch. |
|
Regarding static files, I think it's actually preferable that the api container throws an error when trying to serve static files, because we really don't want it doing that job. The NGINX container should definitely be handling that, and what I've found is that if NGINX is unable to serve the static files it passes the request through to the API container. We should definitely fix the static file serve issue at NGINX, not at the API container. First, after you switched branches, did you remove and rebuild the nginx container? Then, if that still doesn't seem to work, can you let me know what the issue is according to the nginx container logs? |
|
Removing and rebuilding the container didn't work for me. I don't get that error for the first http request, it is occurs on the second http request. For example https://localhost/api/v1/ will work, then I click to go to https://localhost/api/v1/capabilities/, then the error occurs. Here is the nginx log. |
|
@jhazentia When I ran the iq survey it was dying because postgres was running out of memory. It seems I am able to avoid the issue if I reduce the number of frequencies in the survey action. |
|
https://docs.gunicorn.org/en/stable/settings.html#timeout
We're using a |
|
From the gunicorn repo:
Looks like during any task that runs more than 30 seconds (the default timeout) we'll need to explicitly cede ( First step is to optimize database operations, because iq_survey should nominally not take 30 seconds to complete. See #149. |
|
Would we avoid error if individual |
|
@MichaelCotton I wouldn't recommend that approach because it defeats the idea that an action can basically do anything. Instead I'd recommend (in order)
|
|
@djanderson I am still getting error for missing src/static/js with the latest change. It seems the debug toolbar is always looking for the Here is the nginx log: Note that the debug toolbar does work if I comment out the entries in |
|
Merging these changes into master |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes 2 issues:
Dockerfile-nginxfile to give more flexibility over the nginx container and then copies static files into the container instead of mounting. This solves the permissions issue.test ! -e /sdr_unhealthy && test ! -e /scheduler_deadwas passing. The issue was that a timeout of1swas used, meaning that if the healthcheck didn't complete in 1s, the container was marked unhealthy. Since the test isn't actually running a time-sensitive command, this PR bumps the timeout to 3s. This fixed the cycling of otherwise healthy api container in my tests.A few static files were also updated.