Recently I had a power outage and so my Raspi 5 on which Teddycloud was running also was shut off improperly. After starting again Teddyclioud won’t start again. I’m running it via docker compose and the container starts, runs a couple of seconds and then restarts (due to restart: unless-stopped in my compose file). The error message in the docker logs is
ERROR|server.c:0860:server_init| httpServerInit() for HTTPS API failed with code 1
Any hints or tips on how to get it running again? Is there some cache file that may have been corrupted due to the outage and needs to be deleted or anything like that?
I remember that this used to cause some headaches, since I have also running a traefik environment. Since my Raspi is connected via Ethernet and WiFi I had solved this issue by giving it port 443 of the wlan IP address, while traefik gets the same port of the Ethernet IP address. It worked this way before the outage and I haven’t changed the config since several months ago, so I’m fairly certain this is not the problem.
Addendum: I just tested it with traefik shut down, so port 443 should be completely free. netstat confirmed that nothing was using the port. Still got the same error.
Erm.. I have no idea, to be honest. I mean, I write PHP for a living so I do have a basic understanding what is going on there, but it seems that all error constants being used have the value 1. If that’s the case, it would of course be possible to just assign them individual values and see which one is actually being returned.
But I’m not sure if and how I could get this individual code changes running locally.
I am considering just trying to start from scratch and just keeping certs and library. But I am a bit afraid of losing data and/or having to reassign all our custom NFC tags.
What I did was I renamed the config.ini to config.ini.bak and the config.overlay.ini accordingly. Then I started it via docker compose up -d, checked if it was running (it was), shut it down again and then diffed the new ini files with the bak files.
@henryk your suggestion with the already used 443 port wasn’t far off at all.
It seems that at some point I changed the HTTPS Web port (core.server.hhtps_web_port) to 443 instead of 8443. I can’t remember doing so but since there is nobody else that uses the web interface it must have been me. Anyway.. I removed the new ini files, renamed the bak files back to their original name again and changed the port back to 8443 and lo and behold: it works again.
So, if anybody ever has this problem: it is very likely a case of PEBCAK
Particularly around the HTTPS API init, this feels much more like a TeddyCloud configuration mismatch than it does like Docker or Traefik.
The cyclone http server is rather strict; it will just provide a generic error if the https listener is unable to connect precisely as it wants. If the configuration is inconsistent, netstat’s display of 443 as free may not always rescue you. TeddyCloud requires the internal API ports and https_web_port to maintain their normal relationship (8443 vs. 443); if they don’t, the TLS configuration blows up before any meaningful data is recorded.
One issue people overlook is that switching the browser port to 443 interferes not only with the user interface but also with the internal initialization of the HTTPS API server. Thus, even if you get “port is free,” the server init process may still fail.
The quickest approach to reveal this information is really to rename config.ini and let TeddyCloud to renew it. Diffing the regenerated file often reveals the offender right away. Your behavior would be entirely explained if the https web port was configured to 443 rather than 8443.
TL;DR for anybody else experiencing this: presume config.ini first, not Docker, not Traefik, and not the network, if TeddyCloud won’t start and complains about HTTPS API. Configuration drift is usually self-inflicted.
