Thanks, we’ll look at this now and let you know what we find.
Hi again,
The Supervisor’s attempting to bind against /tty/ttyUSB0, however, this terminal does not exist and so it is unable to start the service. I’m assuming this TTY should exist? Is the relevant external device plugged in?
Best regards, Heds
Hi @hedss - a quick reboot from the dashboard got it to bind again and work well - is there a way of me telling what is preventing the supervisor starting?
Hi @bithell,
As Hedley mentioned above, your service was unable to start because it’s stuck in a restart loop, reason for this is that the Supervisor is trying to bind to dev/ttyUSB0 but it doesn’t exist. Can you please check if the relevant device is connected?
The device was connected and working - it just for some reason needed the whole device to reboot for it to bind again - is there a way I could have worked out that that was the issue or is that level of logging only accessible to you?
Is there also a way to tell the supervisor to restart the device after a certain time if it can’t start
Hey @bithell ,
I suggest enabling persistent logging and then connecting to the host OS and checking the logs of the supervisor container through journalctl, as that might give you more info about what’s going on
To add to @jviotti’s response, we provide some device diagnostics to assist in debugging these sorts of issues. Those diagnostics will grab & preserve some commonly used logs and metrics from the device, which can then be shared for support more easily.
This has become a further problem and the device seems to have kicked itself offline now as a result - please could you have a look @jviotti?
Hi,
Unfortunately the device seems to be completely disconnected from our VPN, are you able to check if it is still physically connected to the network?
Kind regards,
Theodor
Hi @telphan , it’s a remote device so it took a very long time to get someone down there sorry but it’s online now, albeit facing this issue of “starting service”
The reason it has been failing, like Hedley mentioned above, is because it’s trying to bind mount /dev/ttyUSB0 which apparently doesn’t exist and fails. You may unblock the device by removing that line from your docker-compose.yml (or changing to the appropriate device) and pushing again.
Does this most likely mean that the device isn’t physically connected or that it’s moved port?
It’s difficult to tell remotely, you can check it when connecting to the host OS, and listing /dev/ttyUSB*. Most of the time the case is that the serial device is not connected, though. Would recommend checking in the hostOS whether it exists at all.
ttyUSB doesn’t exist which explains a lot - guess the next step is to send someone to the device physically
Just an update to say that updating the host os version from the Balena dashboard meant it found ttyUSB0 again successfully and it’s now working