Works fine on a RPi 4 for weeks, then ceases to function #21
Comments
|
I face the same problem on x86. Working well for weeks and suddently it stops submitting new data to influxdb. |
|
Ahh this is the same problem I posted.... I got round it by creating a cron job tear things down and restart them every 3 hours - at least this way I keep some visible monitoring going (I have my monitor set to every 10 minutes (SPEEDTEST_SPEEDTEST_INTERVAL=600) to try and get some granular detail of how poor my ISP is!) |
|
Be good if someone can work out how to handle the JSON response and accept it Y - that would solve the problem. |
|
@R32GUY : On what info do you base your diagnosis that this has sth to do with accepting the license agreement? Can you explain a bit? |
|
I had a similar issue when i was running speedtest-cli from command line - but now i've looked at the code I suspect the problem is that Speedtest in the docker container is just erroring and there is no handled exception to retry...
My return code =2 when it fails (and has been quite a lot, but this could be down to Speedtest or the fact that my internet and DNS resolution is down, so I'm going to try and amend the index.js to handle the error and retry |
|
My Short term solution to fix this is: Stop the containers.. Navigate to /docker-speedtest-grafana/docker/speedtest nano index.js and at the bottom, remove the process exit on error > } catch (err) { Replace with } catch (err) { (I also have a cron job at midnight to stop and restart the services for belt and braces) |
|
I dont speak JS but this looks simple enough, I will give it a go and keep you updated. |
|
Didnt solve the problem, but it seems to catch the actual error message, here is the new log tail: |
|
I think the problem is that the speedtest called by the execa function in the script does not return, i am trying this now: Adding the timeout option to the execa command will not allow the script to hang indefinetly here. Doing this with a fixed time constant is a bit of a hack of course because the timeout value shold probably correspond to the frequency of / time in between the speedtests performed. |
|
This solves the issue, apparently. The same error that lead to hanging speedtest container still occurs in the logs, but i get valid measurements afterwards. @frdmn : I dont know if this is in your interest to fix, but since I was not the only one with that problem, it may be worth a look. The timeout value of 600000 assumes that no single run of speedtest should take longer than 10 minutes, but there may very well be a more intelligent solution to this particular problem. My docker log for the speedtest container now looks like this: |
|
Appreciate the report and investigation on this. I'll try to take a look and fix this as soon as I have a bit more spare time. Of course PR's are always welcome, if someone wants to work on this. |
|
I have the same/similar problem. It worked for the first 3 speed test results, then failed with: My installation this has this in index.js: |
updated getSpeedMetrics based on frdmn#21 (comment)
I got this to run on a rpi4 with a modified docker-compose.yml, just needed to build the "speedtest" container on the rpi4 instead of pulling it from the repository to make it work.
Now I observe the following problem:
After some days/weeks, the speedtest container stops adding new data to the influxdb. In the logs I can see the speedtest container restart due to the node index.js command exiting with some error related to name resolution. No problem with that, shit happens, maybe network is temporarily down for some reason etc..
The "speedtest" container is then automatically restarted as it should be, but does not continue doing its job of performing speed tests, I cant figure out why... docker-compose down + docker-compose up fixes it.
I think the problem is connected to the SIGTERM, see the log below. This happens in the first iteration after the container is restarted.
Any ideas?
The text was updated successfully, but these errors were encountered: