These are some common issues that can occur while using the alwaysAI platform. If your issue is not covered here, reach out to us on our Discord support channel. Many of these issues can be resolved by updating the alwaysAI installation on your system, and moving to the latest edgeIQ version.
aai app install: ssh: Could not resolve hostname pi@raspberrypi: Name or service not known¶
$ aai app install ✔ Target configuration not found. Do you want to create it now? … yes ✔ What is the destination? › Remote device ✔ Found Dockerfile ✔ Please enter the hostname (with optional user name) to connect to your device via ssh (e.g. "firstname.lastname@example.org"): … pi@raspberrypi ⚠ Connect by SSH Process exited with non-zero status code 255 $ ssh -i /home/eric/.ssh/alwaysai.id_rsa -o BatchMode=yes -o StrictHostKeyChecking=no pi@raspberrypi echo ssh: Could not resolve hostname pi@raspberrypi: Name or service not known Cannot connect to your device. Please check the address and try again. ? Please enter the hostname (with optional user name) to connect to your device via ssh (e.g. "email@example.com"):
Causes and Fixes¶
There are many reasons your device might not be findable by the CLI. The simplest reason is that the hostname or IP address could be wrong. Double check that it is entered correctly. Our Raspberry Pi OS image comes with mDNS installed so you could try adding “.local” to your hostname (e.g. firstname.lastname@example.org).
Another possibility is that the device is not connected to the same network as your development computer. Our Raspberry Pi OS image starts WiFi-Connect when the device can’t connect to a network, which makes it easy to connect your device to the WiFi network of your choice.
no permission to read from ‘/home/pi/alwaysai/realtime_object_detector/core’¶
“$ docker build --quiet . error checking context: ‘no permission to read from ‘/home/pi/alwaysai/realtime_object_detector/core’’.”
There is a file in the target app directory that can’t be loaded by docker, likely due to a permissions issue. This is often due to using
To get the Docker build to succeed, you’ll need to delete the core file on the target device. Run
aai app install --clean to remove the file. To prevent core dumps, close your app using the “stop” button on the Streamer, or any other method of cleanly exiting your app.
RuntimeError: Model alwaysai/mobilenet_ssd not installed!¶
A model used in your app.py is not installed using the CLI. It may not be added as an app dependency, or simply not installed on the device.
First, check your app config using
aai app show. If there aren’t any models added to your app, the output will look like this:
$ aai app show Models: None Scripts: start => "python app.py" Target: docker container on this host
To add a model, go to the alwaysAI Model Catalog, pick out your model, and follow the instructions to add the model to your app.
If the model is added your config might look like this:
$ aai app show Models: alwaysai/mobilenet_ssd@4 Scripts: start => "python app.py" Target: docker container on this host
This means that you added a model using the CLI, but you haven’t run
aai app install after to install the model to the target device or development host.
OSError: [Errno 98] Address already in use¶
The Streamer can’t bind to it’s default port due to another connection occupying the port.
This is most often caused by another alwaysAI app that has been left running, and the simplest solution is to reboot the target device. It could also be caused by a connection to the same port on your development machine. Rebooting your development machine may also help.
Stuck on “Copy application to target”¶
This issue most commonly occurs when using the alwaysAI CLI on Windows.
This issue will happen if there are multiple entries for your target device in the known_hosts file, indicated by these logs:
Warning: the ECDSA host key for 'alwaysai' differs from the key for the IP address '192.168.1.10' Offending key for IP in C:/Users/alwaysai/.ssh/known_hosts:2 Matching host key in C:/Users/alwaysai/.ssh/known_hosts:5
To fix this issue, delete the offending key in the known_hosts file and run
aai app deploy again.
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock¶
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock
The current user doesn’t have rights to run the Docker daemon.
Add the current user to the
sudo usermod -aG docker $USER
App prints “This is a stub of an alwaysAI application”¶
$ aai app start This is a stub of an alwaysAI application
This happens when you run an empty alwaysAI application. When you run
aai app configure in a directory without an alwaysAI app, it creates this empty application to get you started. However, this can also happen when you run the
aai commands in an unexpected directory.
Docker: failed to start daemon¶
If you get an error when installing
dockerd in the foreground to get the full error message:
$ sudo dockerd
There is a simple workaround if your error message looks like this:
failed to start daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables --wait -t nat -N DOCKER: iptables v1.8.2 (nf_tables): CHAIN_ADD failed (No such file or directory): chain PREROUTING (exit status 4)
Debian Buster has changed how IP tables are managed from Debian Stretch, causing a mismatch when docker tries to work with the IP tables.
You can resolve this issue by setting the OS to use the legacy IP tables management:
$ sudo update-alternatives --set iptables /usr/sbin/iptables-legacy $ sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy $ sudo service docker start