# \[SOLVED\] Short-lived containers on resin.io **URL:** \ **Category:** Product support\ **Created:** [September 15, 2018, 3:35pm UTC](https://forums.balena.io/t/solved-short-lived-containers-on-resin-io/3973 "2018-09-15T15:35:25Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![kkom](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/kkom/32/1152_2.png) [@kkom](https://forums.balena.io/u/kkom)\ **Post date:** [September 15, 2018, 3:35pm UTC](https://forums.balena.io/t/solved-short-lived-containers-on-resin-io/3973/1 "2018-09-15T15:35:25Z")
Hey, Does [resin.io](http://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](http://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](http://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](http://resin.io) is absolutely amazing – creating this project was a pleasure! Thanks for making it happen! Best, Konrad ---
**Author:** ![floion](https://avatars.discourse-cdn.com/v4/letter/f/45deac/32.png) [@floion](https://forums.balena.io/u/floion)\ **Post date:** [September 16, 2018, 7:50am UTC](https://forums.balena.io/t/solved-short-lived-containers-on-resin-io/3973/4 "2018-09-16T07:50:01Z")
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](https://docs.resin.io/reference/base-images/base-images/#init-system) for documentation on this ---
**Author:** ![kkom](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/kkom/32/1152_2.png) [@kkom](https://forums.balena.io/u/kkom)\ **Post date:** [September 16, 2018, 11:23am UTC](https://forums.balena.io/t/solved-short-lived-containers-on-resin-io/3973/5 "2018-09-16T11:23:26Z")
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: ![17](https://global.discourse-cdn.com/balena/original/2X/9/9258d235f19e81b59faeb8a01f4af18a6bf33f82.png) Is there a way to make the hypervisor happy with a container that exists immediately? ---
**Author:** ![floion](https://avatars.discourse-cdn.com/v4/letter/f/45deac/32.png) [@floion](https://forums.balena.io/u/floion)\ **Post date:** [September 16, 2018, 1:50pm UTC](https://forums.balena.io/t/solved-short-lived-containers-on-resin-io/3973/6 "2018-09-16T13:50:09Z")
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](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. ---
**Author:** ![floion](https://avatars.discourse-cdn.com/v4/letter/f/45deac/32.png) [@floion](https://forums.balena.io/u/floion)\ **Post date:** [September 16, 2018, 2:05pm UTC](https://forums.balena.io/t/solved-short-lived-containers-on-resin-io/3973/11 "2018-09-16T14:05:24Z")
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, [Compose file version 2 reference | Docker Docs](https://docs.docker.com/compose/compose-file/compose-file-v2/#restart) ---
**Author:** ![kkom](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/kkom/32/1152_2.png) [@kkom](https://forums.balena.io/u/kkom)\ **Post date:** [September 16, 2018, 2:32pm UTC](https://forums.balena.io/t/solved-short-lived-containers-on-resin-io/3973/12 "2018-09-16T14:32:15Z")
Thanks a lot! Configuring `restart` on the container achieves exactly what I wanted. In fact, you can do it a bit better: ```auto restart: on-failure ``` This way I’ll be alerted by a continuously restarting container that the configuration task did not succeed. 🙂 For future reference, here is the commit that implements the change according to your suggestion: > **[instead of hacking the container to wait indefinitely, instruct docker to......](https://gitlab.com/komorowskik/resin-dynamic-dns-updater/commit/fa4221d84887be0f16cfa7c8615b3e6f76fae069)** > > instead of hacking the container to wait indefinitely, instruct docker to restart it only on failure And here is the view of the Resin dashboard after applying the changes (note that the `configure` container is meant to be Stopped): ![desired%20outcome](https://global.discourse-cdn.com/balena/original/2X/0/0857ecf1db9f28529ea4578bbcf4740dbc34ab20.png) 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.