I have just built a new server for my spark 4. The install process seemed to complete normally with out any errors, however when I try to access the UI with the ip address of the server I receive a “page not found”
I have attached a link for the logs.
Any assistance would be appreciated.
Regards
It appears the Nginx UI container is trying to listen on a IPv6 socket in the container, even though it is unavailable.
I’ll have a look in a bit why it’s convinced itself it could even do that.
What kind of host are you using? It looks to be a x86_64 ubuntu machine, but it’s unclear whether this is a VM or a native OS.
I pushed a potential fix for the issue. Could you please try it out by editing the docker-compose.shared.yml, and editing the image property for the ui service?
From:
ui:
image: brewblox/brewblox-ui:${BREWBLOX_RELEASE}
To:
ui:
image: brewblox/brewblox-ui:fix-ipv6-listen
Then run brewblox-ctl up and it will download and use the image. The change will be reverted the next time you run brewblox-ctl update.
Hi there,
Good news your change has fixed the issue and I can now access the UI. However I can not add the Spark 4 service for some reason.
I ran brewblox-ctl add-spark, it found the spark and I chose the option to add it. I then ran brewblox-ctl up but the spark did not appear in the UI.
The system has been installed on a HP thin client t630. It is a bog standard install from Ubuntu 22.04 server.
Good to hear the UI issue is fixed. The change will be included in the next update.
If a hard refresh (ctrl-F5) of the UI does not cause the service to appear in the sidebar, could you please run brewblox-ctl log again?
OK did hard refresh and even a reboot spark service still not showing up.
output of brewblox-ctl log
This is referring to the “spark4” service? Everything seems in order there.
The “services” section in the sidebar can be collapsed. This is not the case?
If you switch the UI between http and https, does this make a difference?
If you open the UI developer tools (ctrl+shift+i), navigate to the network tab, and reload the page, does it show an active websocket stream to eventbus ?
Right switching between http and https makes no difference at all.
The developer options appear to show an entry for the eventbus, although the size column is reporting 0B. I dont know whether that is useful or not. Also in the UI bottom right of the page it say in red “no eventbus”
I have attached a snippet of the developer output.
Hope this helps
If there’s no eventbus, new services indeed won’t be reported. There should only be a single eventbus entry - the multiple entries are attempted reconnects.
Could you please right click on the network tab, and export as HAR?
Does the issue also occur if you use a different browser?
I did have a feeling that you should only see one entry for the eventbus and it was continually retrying.
I have tried to open the UI with both Opera and Microsoft Edge, both with the same result.
I have tried to attach a the .har file but it is too large. I have put the file in a dropbox folder. Link below.
Again, I pushed a possible fix, this time for the eventbus service:
eventbus:
image: image: brewblox/mosquitto:fix-ipv4-eventbus
On the whole, it appears you disabled IPv6 support in the kernel, and this is causing some unexpected issues in various Docker containers.
OK. You are worth you weight in gold. That fix sorted it. I can now see the spark 4 with all its blocks.
You are correct I did disable ipv6 in grub. My thinking was that the problems that ipv6 has caused brewblox in the past. I thought that it would help. Maybe I was thinking to far ahead.
Maybe it would be better to not to disable service without understanding implications within the software and leave ipv6 enabled so save any more issues.
I did not think that it would cause all the problems that it did and did not mean to waste valuable time.
once again thanks for your efforts
Good to hear it works now! I admit, disabling kernel support for IPv6 caused a few more problems than I’d expect. We hadn’t really explored the option, as asking / recommending users to tweak kernel parameters was considered overly invasive.
Agreed. The software has to work for the masses not for the individuals who go under the bonnet of the kernel without really understanding the consequences for installed software. I will leave well alone in future.
Once again thanks