Looks like there was two simultaneous attempt to start the device. That’d explain why all the port bindings seem to fail - the container that I’m ssh-ing may be the one the second one shown on the log.
What do you guys think? Any ideas why this may be happening on the preloaded image?
Hi. Can you detail how you diagnosed your app is not working as expected?
As for the logs shown here, not sure that is really the problem, I think that the problem is just how the supervisor currently displays the logs for a preloaded app but in the background it should be doing the right work. @pcarranzav can you chime in about these logs here?
Hi @daniel.lee - I think it might be indeed that you have a duplicated container issue.
It appears that the supervisor applies the config.txt changes and triggers a reboot, but before the device reboots it actually starts the container. There’s a problem in how we store the device state that might cause an additional container to be started if the device reboots before we store some information about the container into an internal database - this is going to be fixed in resin-supervisor#465 which is a rather large work in progress.
In the meantime, I’ve just PRd this resin-supervisor#472 which should avoid the supervisor starting the container before the reboot, effectively solving this particular issue for you. Hopefully we can get this out soon.
Sorry @daniel.lee, your post just made me realize that the PR I had made was insufficient. I just PRd this change https://github.com/resin-io/resin-supervisor/pull/484 that now should really fix the issue for you. Hopefully it will be merged and deployed soon.
Cheers! And thanks for your patience
Hey @imrehg@Sqweelygig. I tried preloading (resin preload), but it doesn’t seem to work!
Steps:
Download Resin OS 2.3.0+rev1 (prod) from my resin application dashboard
Add a network manager config file to the image to make our 3g modem work
preload using resin preload
Burn the image, insert to device
Observations:
The device shows up in the wrong application (what?). Our team manages two applications; one for prod and another for testing/staging. I download the staging image and preloaded the staging app (i.e. resin preload --app {Staging App Id}), and yet the device shows up as a device in the production app. I have no idea why.
Notice that staging app is started, killed, and then prod app is downloaded (only to fail!). I’ll be happy to hand over the device url with the permission for you guys to take a look at the supervisor.
Yeah it would be good if we could take a look, please can you grant access for 24 hours.
To grant access: navigate to that app or device, find Actions in the sidebar, click “Grant support access”, and choose the timespan. Then please reply to this support message with the URL targeting the app or device to investigate. (For example: https://dashboard.resin.io/apps/11111/devices/22222/summary)
Actually run across this device today, running the hostOS updates for your fleet.
First, the important thing: are you using iptables in your application? Because it seems like that the iptable rules are changed when the user application starts, and that breaks networking (dns resolution) in the docker containers (both the application and the supervisor).
ResinOS 2.3.0 contains a change that fixes the docker bridge’s IP address. This was needed, because automatic IP for docker0 interface run into issues on some network setup where conflicting IP addresses were assigned to the interfaces. In the new setup that won’t happen. On the other hand, whoever was relying on the previous, automatic setting to be fixed, will have issues. That seems to be happening in your case!
Would recommend looking into your application and before preloading trying to create a regular 2.3.0 or newer device that runs your application correctly!
Regarding the other issue of the device showing up in the wrong application, that’s very strange, and looking into it!
