Local Webserver Failure

For some reasons - I don’t understand - my farmbot web app server fails after some time. The server is a small Zotac Zbox with enough power to host the web app. Maybe it get hot when I use the web app to control the farmbot and therefore reduces its performance? As it lives under the solarpanel.
I added the error code I get, maybe @RickCarlino or @Gabriel can understand what it means.
I could buy another PC, but I need to be sure what really is the issue first… thanks

ErrorMessageWebApp.pdf (1.6 MB)

Added a Fan to the case because I expected temperature to be an issue and for some time the server was running, but the next evening it was broken down with this error message:

ErrorCode_2.pdf (193.0 KB)

@derletztename

It looks like Webpack either crashed or was never running. Definitly not a hardware problem.

You can try to reboot and reloaod the server (rails api:start).

If that doesn’t work, please send me the error log when running npm run webpack inside of the API directory.

So I could connect to the server for quite some time, when the fan was on top and running. Therefore I still have the strong feeling it’s hardware and temperature related. I just bought a more powerful mini pc with improved cooling. Also I did what you asked for and here are some screenshots of what happened:

Nothing happend after that for about 30 minutes. So I killed it with ctrl+c…
Does this help you in any way to understand what’s going on?

Did the screenshots help you?
I got the new Intel NUC kit PC on the field and hooked it up. It run for quite some time and slightly faster than the Zotac box, but got a similar (same?) error as well:
ErrorMessageWebApp_newServer.pdf (1.6 MB)

So I tried some more things. If I run the server in my home, it’s running without an error for a long time. I brough home the mobile router, still running fine, I heated up the mobile router, still running fine. I checked the supply of energy. It’s very constant.
But then there is no farmbot in my office, so maybe it’s farmbot related?
I tried to run MLH farmware and got an error. Without understanding I asked Eugene about it (MLH - Github)
And he suggested an API issue maybe?

Hello, this means the API_TOKEN that your raspberry pi gave to firmware is not good for your server
Did you try other Farmware? The problem shall be universal

I tried first party farmware, which runs fine.
Might those problems be related?

Maybe related to:

?

Back on the field with Server and Router and connected to the Farmbot, the error came up again pretty soon.
I got the feeling it’s mostly comming up while opening the farmware page or the sequences page, but not device and controls pages. I could even, after the first error message (pic 1) came up on the farmware page, go back to the controls page and move the farmbot. Only when I reload the page (F5) on the farmware page, the webpack crashes like before (pic 2). Does this narrow the problem a little bit?

This is the error message popping up in the webbrowser btw:

{“message”:“Loading chunk 1 failed.\n(error: http://192.168.0.198:3808/webpack/1.js)”,“stack”:“Error: Loading chunk 1 failed.\n(error: http://192.168.0.198:3808/webpack/1.js)\n at HTMLScriptElement.onScriptComplete (http://192.168.0.198:3808/webpack/app_bundle.js:115:29)”}

I just realized that my firmware might be not compatible with the local server situation. I’ll take a look on this when I am back from vacation.

Can confirm that. Looks like the request function throws errors due to unknown SSL protocols.

@derletztename I see your first screenshot of webpack and that looks fine- what about the second set of screen shots here? Do you see any errors in the logs?

It looks like the server is trying to download manifest.json from localhost, which is not going to work if the server is not running on the local machine. The manfiest.json is calculated using the API_HOST environment variable. If it can’t be found (or there is a spelling/capitalization issue, etc), it will use localhost, which won’t work in your use case.

I just tested locally by accessing the API from a different machine on my LAN and I do not observe any issues with loading the WebPack manifest. Perhaps there is a configuration issue somewhere.

What does your application.yml look like? If API_HOST is incorrect, the browser won’t be able to load the page.

I’m fairly certain this is a software or configuration issue.

So the typical procedere is like this:
I start the web server and do soemthing with the farmbot for a while and after a “random” time, the first pictures message appears. And if I update the webpage, the second follows. Sometimes farmbot works quite good, then I leave for the day and at the next day, the second picture message is in the browser. Directly.

At first I thought the PC might overheat and therefor timeout one of its services, but it also happens with the improved PC and in the evening when its 18°C or less. Then I thought maybe the wifi goes done and the services can’t reach each other for a short moment and therefore break down, but at home it was stable for a long time with the same mobile network. So it must have to do something with the farmbot. It only happens when server works with farmbot!
Sorry, only pictures right now from application.yml:

@derletztename Everything looks good if 192.168.0.198 is the correct IP, and it is accessible from other machines in your LAN (it sounds like it is).

What errors do you see in the server logs? I see the screenshots you sent earlier, but I would like to see the API’s logs also, not just the webpack logs.

One way to get a better look at logs is to run the services independently in different terminal windows.

So instead of running rails api:start and rails mqtt:start you would run all of these commands separately (so that the logs are easier to read):

  • ./node_modules/.bin/webpack-dev-server --config config/webpack.config.js
  • rails r lib/log_service.rb
  • rails s -e development -p ${API_PORT:-3000} -b 0.0.0.0
  • rake jobs:work
  • rails mqtt:start

This does the same thing as rails api:start, but it will make it easier to spot errors in the server logs since they will all have their own output buffer.

Please try this and send me the error logs when the problem happens next.

Also, you should investigate the error in your previous log that says failed to remove key.... I have never seen that on any machine before and it might be related to the configuration of your local Linux distro.

1 Like