[SOLVED] Short-lived containers on resin.io


#1

Hey,

Does resin.io always assume that every container needs to continuously keep running?

I’ve built a simple Dynamic DNS application which consists of two containers. One configures the Dynamic DNS service settings (based on environment variables) and then exists immediately (edit: added for clarity). Another one checks the device’s IP address every 5 minutes and performs an update if necessary.

Currently, I need to insert a dummy wait statement, so that resin.io does not try to continuously restart the first one (I assume this operation is not very power efficient, especially given that it’s unnecessary):

Is there a way to make resin.io be okay with a short-lived container? Or is there a better solution to my problem? Ideally I’d like to keep the container separation between the configuration and IP update.

(On a related note, I suppose it would be more efficient to fire up the IP update container every 5 minutes. Now it takes up RAM on just waiting for another check. This may or may not matter, depending on whether you can run other containers only when this one is down.)

In any case, resin.io is absolutely amazing – creating this project was a pleasure! Thanks for making it happen!

Best,
Konrad


#4

Hi. I believe you need to set ENV INITSYSTEM on in your Dockerfile . See https://docs.resin.io/reference/base-images/base-images/#init-system for documentation on this


#5

Thanks for your reply! Can you elaborate how this will help? I thought that INITSYSTEM was only controlling processes inside the container, while my problem is with the hypervisor.

The hypervisor is unhappy that my configure container exits immediately, so it restarts it. And then my container exists immediately again, and this keeps going forever.

Here is a screenshot showing it:

Is there a way to make the hypervisor happy with a container that exists immediately?


#6

Hi. I think I have misunderstood what you wanted. I pointed you to using systemd in the container so that the container finishes the work and remains running, without being restarted. You could leave your container always running and just do it’s intended job every 5 minutes.
But it seems you want the container to exit and not restart until after 5 minutes or so. In such a case, you could employ the use of the device config variable RESIN_APP_RESTART_POLICY which should support docker’s restart policies as outlined here: https://docs.docker.com/engine/reference/run/#restart-policies---restart
I don’t find this documented anymore in our docs, let me ask around and get back to you.
Also, not sure how you would go around to have these restart policies only for one of your containers.


#11

As a follow-up, the colleague working on the supervisor side of things just pointed me that:

restart: no

in the service definition in the docker compose should do what you need.

For reference, https://docs.docker.com/compose/compose-file/compose-file-v2/#restart


#12

Thanks a lot! Configuring restart on the container achieves exactly what I wanted.

In fact, you can do it a bit better:

restart: on-failure

This way I’ll be alerted by a continuously restarting container that the configuration task did not succeed. :slight_smile:

For future reference, here is the commit that implements the change according to your suggestion:

And here is the view of the Resin dashboard after applying the changes (note that the configure container is meant to be Stopped):

PS: ddclient is still running continuously, and just waits 5 minutes between IP address checks. I think that this is fine - I didn’t see an option in the compose file reference to schedule the container to start from scratch every 5 minutes. It’s probably even more power efficient to have it wait 5 minutes between doing work, rather than restart all the time.