Connection refused at $BALENA_SUPERVISOR_ADDRESS

Hi guys!

I’m using a private server in the cloud to run Balena OS.
Fleet Raspberry Pi Zero W’s are running raspberrypi_2.80.8_rev1_prod.img.

All worked great until I had to change the Server’s password and with it the corresponding ca.crt certificate!

deploys still run without any error and pre-loading works fine too.

However, the logs show errors around the $BALENA_SUPERVISOR_ADDRESS curl patch.

Here’s the code in which throws the error (it did work fine before). The curl throws the error.

# Change hostname
echo "yokoso" > /etc/hostname
hostname yokoso
hostnamectl set-hostname yokoso --static
curl -X PATCH --header "Content-Type:application/json" \**
    --data '{"network": {"hostname": "yokoso"}}' \**
    "$BALENA_SUPERVISOR_ADDRESS/v1/device/host-config? **

Here are the corresponding logs (with the Connection refused):

[Logs]    [10/15/2021, 10:31:14 AM] Rebooting
[Logs]    [10/15/2021, 10:35:26 AM] Supervisor starting
[Logs]    [10/15/2021, 10:33:27 AM] [yokoso] Systemd init system enabled.
[Logs]    [10/15/2021, 10:33:28 AM] [yokoso] systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[Logs]    [10/15/2021, 10:33:28 AM] [yokoso] Detected virtualization docker.
[Logs]    [10/15/2021, 10:33:28 AM] [yokoso] Detected architecture arm.
[Logs]    [10/15/2021, 10:33:28 AM] [yokoso] Set hostname to <yokoso>.
[Logs]    [10/15/2021, 10:34:14 AM] [yokoso] curl: (7) Failed to connect to port 48484: Connection refused

Any help is more than welcome!

Hi @imolitor,

There are several possible causes for what may be wrong:

  • Supervisor API has not started up at the time of running the curl command. This is possible, seeing as your logs list Supervisor starting(10:35:26 AM) as occurring after the curl (10:34:14 AM). I’m not sure if this is an error in the logs or just that system time hasn’t synced up yet.
  • Something else, which we can begin to understand if you try running the curl with -v specified.

To check that the API key is valid, assuming you’re running a new enough Supervisor, run the following to see if the output of echo $BALENA_SUPERVISOR_API_KEY matches what the Supervisor has in its DB:

balena exec -it balena_supervisor node // This may be resin_supervisor depending on OS version, run balena ps to check
sqlite3 = require('sqlite3')
db = new sqlite3.Database('/data/database.sqlite')
db.all('select * from apiSecret',console.log)

BALENA_SUPERVISOR_API_KEY should match the corresponding scoped entry for the service that you’re running from. If this is verified and doesn’t appear to be the issue, the problem could be one of the other ones listed above. I think in any case, pasting the output of curl -v... is a good place to start. Thanks!


Also, where are you running this script from? In a container? Does the container have the io.balena.features.supervisor-api label specified, per docker-compose.yml fields - Balena Documentation?

Yes, the docker-compose.yml has the API label specified:

build: ./yokoso
network_mode: host
privileged: true
restart: always
io.balena.features.dbus: ‘1’
io.balena.features.kernel-modules: ‘1’
io.balena.features.firmware: ‘1’
io.balena.features.supervisor-api: ‘1’
io.balena.features.balena-api: ‘1’

Thanks for this. I’ll have a look into it.

Strange is, that there were no changes to any of the code. Just the server password and with it the ca.crt certificate changed.