My question: Is the Tom Ai service working SparkBox AI replied: I couldn't reach the AI service — this box's connection to it timed out (EAIAGAIN). That's the network path between your box and our servers, not the app itself: check your internet/VPN, then run sudo sparkbox doctor (its Container Egress check tests that same path). If that's green and this keeps happening, post in d/sparkbox with your install ID and this code so we can check our side. What I still need help with: How do I narrow down what the issue is ... is the a 'service status' indication that lets us know if the backend Ai is up and running. My VPN and other network services all all running ok, so it seem just to be a problem accessing the Tom Ai service
9 replies
Chris wrote:
Hi kraken99, I'm sorry about the automated reply earlier. Two things in it were wrong. It said the connection "timed out," but the error means the box could not look up the AI service's address for a moment. That is a short name-lookup hiccup, not a timeout, so pointing you at your internet and VPN was the wrong place to look when your VPN and other services are fine. It also asked you to post your install ID here. Please don't. You don't need to share it for this. I couldn't find a live status indicator for the AI service on the box, so I can't tell you from here whether it is up. The error itself is the signal. Next check: wait two or three minutes and ask Tom AI again. If it still fails after a few tries, run sudo sparkbox doctor and reply with only the [Container Egress] lines. Please also tell me your SparkBox version and whether the box is a Linux server, a NAS, or Windows with WSL. That decides the next step. I've flagged this wording to the team so the next reply doesn't repeat it.
kraken99 wrote:
container egress result from running sparkbox doctor [Container Egress] [OK] Apps can reach webhook.tomsparkbox.com over sbproxy (their real network) [OK] Docker's default bridge can reach tomsparkbox.com (dashboard Update button) I'm using Debian 13.7 headless server, Sparkbox version v1.7.28 and using the Legend Interface Dashboard, running on an N150 mini-pc
Chris wrote:
Thanks, kraken99. Those lines are useful, and I need to correct my last reply. I said the doctor's Container Egress check tests the same path as Tom AI. It doesn't. It checks webhook.tomsparkbox.com and tomsparkbox.com, not the address Tom AI connects to, so its green lines don't clear that path. I'm sorry I presented it as if they did. I've passed this to the team so the next reply doesn't repeat it. What the error means: the box could not look up the AI service's address for a moment. That is a short name-lookup failure, not a timeout, and the box's own egress check doesn't show whether it will happen again. You're on SparkBox 1.7.28 on Debian 13.7. The latest published release is 1.7.33. I can't tie this lookup failure to a particular release yet, so I'm not saying an update will fix it. Next check: ask Tom AI again in a few minutes. If it fails again, reply with the time it failed and whether a second try worked. That tells us whether the failure is momentary or repeating.
kraken99 wrote:
The Tom Ai service is still failing with the same error as above, but I also noticed that my daily Sparkbox system update failed this morning and is still failing when I manually check for updates I get a 'Couldn’t check for app updates — try again shortly.' ... obviously trying again doesn't work.
Chris wrote:
Thanks, kraken99. A name-lookup failure on the Tom AI service and a failed update check on the same morning is worth checking together, but I can't tell from here yet whether they share a cause. The "Couldn't check for app updates" message means the dashboard could not load its update list. On its own it doesn't say why. One read-only check, run on the box: sudo docker exec sb-dashboard node -e "require('dns').lookup('api.tomsparkbox.com',(e,a)=console.log(e?e.code:a))" If it prints an IP address, the dashboard container can resolve the AI service right now. If it prints an error code such as EAIAGAIN, the lookup is failing inside the dashboard container. Reply with the line it printed and the time you ran it. For the failed daily update, send the exact wording it showed and the time it failed, so we can see whether the two failures overlap.
kraken99 wrote:
When I run the suggested command I get the error code EAIAGAIN .... these two issues are overlapping as both are current right now
Chris wrote:
Thanks, kraken99. That result matters. The dashboard container cannot look up the AI service's address right now, and your VPN and other services are fine. Your version (1.7.28) already includes an automatic retry for a brief lookup failure, so a failure that keeps coming back for about half an hour is not a brief blip. I don't yet know why it happens, and I won't guess at a cause or ask you to rebuild anything. The next check runs on the box itself, outside the container: getent hosts api.tomsparkbox.com Please post the one line it prints, or say that it printed nothing, along with the time you ran it. If it prints an address, the box can resolve the name, which points at the path between the dashboard container and the box's DNS. If it prints nothing, the box itself cannot resolve the name. I can't yet link the failed update check to this lookup failure, so I'm not treating them as the same cause.
kraken99 wrote:
This was the response from the lookup check 2606:4700:3032::6815:3dbb api.tomsparkbox.com 2606:4700:3035::ac43:d50b api.tomsparkbox.com
Chris wrote:
Thanks, kraken99. I need to correct my last reply first. I said your version already has a retry that covers this. That was wrong, and I'm sorry. The retry makes only two quick attempts, about one second in total, so it cannot explain a failure that lasts half an hour. What I know has been corrected, so the next person doesn't get the same answer. Here is what your result shows. The box can resolve api.tomsparkbox.com, so its own lookup works. The failure is only in the dashboard's lookup, so your internet, your VPN and our servers are not the cause right now. The result listed only IPv6 addresses. That may mean the box's resolver answers the IPv6 lookup but not the IPv4 one. That is a hypothesis, not a finding yet. One read-only check on the box: getent ahostsv4 api.tomsparkbox.com Post the line it prints, or say that it printed nothing, and the time you ran it. I can't yet say whether the failed update check has the same cause, so I'm keeping it separate for now.