# Lock file is not preventing updates

**URL:** <https://forums.balena.io/t/lock-file-is-not-preventing-updates/681>\
**Category:** Product support\
**Created:** [March 20, 2017, 3:42pm UTC](https://forums.balena.io/t/lock-file-is-not-preventing-updates/681 "2017-03-20T15:42:37Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![flavia](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/flavia/32/104_2.png) [@flavia](https://forums.balena.io/u/flavia)\
**Post date:** [March 20, 2017, 3:42pm UTC](https://forums.balena.io/t/lock-file-is-not-preventing-updates/681/1 "2017-03-20T15:42:37Z")

</div>

Hi!

We use /data/resin-updates.lock to have more control over when to run updates on devices (see for example [https://resin.io/blog/scheduling-updates-with-resin-io/](https://resin.io/blog/scheduling-updates-with-resin-io/)).

But the last couple of times we updated (did a git push), we saw devices being updated which had the /data/resin-updates.lock file.

We checked and the “ENABLE LOCK OVERRIDE” button was not enabled (it was yellow). Another time we had some with “enable lock override” enabled and some not, and they were all updated regardless.

Is this a bug, or did the functionality for this change?

Thanks!!  
Flavia

---

<div class="post-metadata">

**Author:** ![pcarranzav](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/pcarranzav/32/94_2.png) [@pcarranzav](https://forums.balena.io/u/pcarranzav)\
**Post date:** [March 20, 2017, 3:55pm UTC](https://forums.balena.io/t/lock-file-is-not-preventing-updates/681/2 "2017-03-20T15:55:15Z")

</div>

Hi @flavia,  
We’ve had some issues with the update lock in the past, especially if the devices reboot. What host OS and supervisor versions are your devices using?  
It also depends on how you’re taking the lock - if you’re not using an exclusive open it’s possible that the supervisor has taken the lock before. What procedure are you using to take the lock? Could you maybe share the part of your code that handles that?

We’re rolling out a [new update lock with supervisor 4.0.0](https://github.com/resin-io/resin-supervisor/pull/395), the lock location will change but it will make it way more robust.

---

<div class="post-metadata">

**Author:** ![flavia](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/flavia/32/104_2.png) [@flavia](https://forums.balena.io/u/flavia)\
**Post date:** [March 21, 2017, 8:22am UTC](https://forums.balena.io/t/lock-file-is-not-preventing-updates/681/3 "2017-03-21T08:22:43Z")

</div>

Hi Pablo,

Ah, sorry, forgot to mention the versions we are using 🙂

On two devices where it happened we are using Resin OS 2.0.0-rc1.rev1, supervisor version 4.

But I think the other one we are using Resin 1, not 100% sure.

I’m not sure what you mean by this:

> It also depends on how you’re taking the lock - if you’re not using an exclusive open it’s possible that the supervisor has taken the lock before.

To enable locking, we create a file: /data/resin-updates.lock, that’s all. It’s always there, and to perform an action we Enable lock override -at least that’s the idea.

So for what we did in this case there is no code involved.

Does it make sense?

Thanks,  
Flavia

---

<div class="post-metadata">

**Author:** ![fokko](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/fokko/32/322_2.png) [@fokko](https://forums.balena.io/u/fokko)\
**Post date:** [March 21, 2017, 9:22am UTC](https://forums.balena.io/t/lock-file-is-not-preventing-updates/681/4 "2017-03-21T09:22:58Z")

</div>

@pablo @flavia I believe the other device was `Supervisor 2.7.1` and `Resin OS 1.19.0`.

---

<div class="post-metadata">

**Author:** ![imrehg](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/imrehg/32/36_2.png) [@imrehg](https://forums.balena.io/u/imrehg)\
**Post date:** [March 21, 2017, 11:21am UTC](https://forums.balena.io/t/lock-file-is-not-preventing-updates/681/5 "2017-03-21T11:21:37Z")

</div>

@flavia @fokko can try out `lockfile-create` (from [mail-lock](https://linux.die.net/man/1/mail-lock), it should be available from [`lockfile-progs`](https://packages.debian.org/jessie/lockfile-progs) on Debian for example):

```auto
#!/bin/bash

# For Supervisor >=4.0.0
LOCKFILE=/tmp/resin/resin-updates
# For supervisir <4.0.0
# LOCKFILE=/data/resin-updates
lockfile-create ${LOCKFILE}
lockfile-touch ${LOCKFILE} &
# Save the PID of the lockfile-touch process
LOCKING_PID="$!"

# Do the things that that shouldn't be interrupted
while : ; do
  echo "Important stuff with lock (PID ${LOCKING_PID})"
  sleep 5
done

```

Would kill/remove lockfile with:

```auto
kill "${LOCKING_PID}"
lockfile-remove ${LOCKFILE}

```

There are some more examples [in the documentation](https://docs.resin.io/runtime/update-locking/#taking-the-lock), but we’ll add more info in the future too, locking should become better & more usable.

---

<div class="post-metadata">

**Author:** ![pcarranzav](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/pcarranzav/32/94_2.png) [@pcarranzav](https://forums.balena.io/u/pcarranzav)\
**Post date:** [March 21, 2017, 4:50pm UTC](https://forums.balena.io/t/lock-file-is-not-preventing-updates/681/6 "2017-03-21T16:50:08Z")

</div>

@flavia, @fokko check the [recently updated docs](https://docs.resin.io/runtime/update-locking/#location-of-the-lockfile) - in supervisor v4.0.0 there was a breaking change and the lock is now at `/tmp/resin/`. The old lock location will only be supported in ResinOS 1.X. So if you’re switching to 2.0, you should try the new lock location as the old one (`/data/`) will be ignored. Hope this clarifies the mystery!

I also recommend you follow @imrehg’s advice. Simply creating the file causes the risk that the supervisor can be trying to take the lock at the same time, so you can’t be sure that the lock is yours unless you use something to create the lockfile exclusively. Also ensure that your app always takes the lock immediately after startup, as the lock is always cleared automatically on reboot.

---

<div class="post-metadata">

**Author:** ![flavia](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/flavia/32/104_2.png) [@flavia](https://forums.balena.io/u/flavia)\
**Post date:** [March 24, 2017, 8:36am UTC](https://forums.balena.io/t/lock-file-is-not-preventing-updates/681/7 "2017-03-24T08:36:52Z")

</div>

Thanks! That explains a lot 🙂

I have a question about the way we are using the lock.

We have many devices in one application, and **we want to be able to have full control about when we update them. So we want to update them one by one** , make sure everything goes alright, go on to the next, etc.

So what we (want to) do: all the devices have the resin-updates.lock by default. We set it up in the Dockerfile with a command like this:

`CMD touch /data/resin-updates.lock;`\*

Then we run a [(python) script](https://github.com/30mhz/resin-utils/blob/master/resin_devices_update.py) which uses the Resin API to iterate over an application’s devices and prompts the user to update each device. For that, it calls supervisor.update forcing a lock override to update each device… And we do this one device at a time.

This is actually based on a recommendation from @petrosagg if I remember well, but maybe things have changed in the Resin architecture for Resin 2, and this is not the right way to go any more.

So is this a good way of solving this, or should we be doing something else? Is it ok to have the lock permanently except if we want to update? **What is the Resin-recommended way of updating devices one by one?**

- Actually from what I read from a previous message in this post, I learned we have to acquire the lock in another way. But is it possible to do it from the Dockerfile?

(I can post this a separate thread if that’s better 🙂)

Thanks!!

---

<div class="post-metadata">

**Author:** ![pcarranzav](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/pcarranzav/32/94_2.png) [@pcarranzav](https://forums.balena.io/u/pcarranzav)\
**Post date:** [March 24, 2017, 9:38pm UTC](https://forums.balena.io/t/lock-file-is-not-preventing-updates/681/8 "2017-03-24T21:38:51Z")

</div>

@flavia,  
Yeah that way of having control of updates is still the way to go (only with the new lock at /tmp/resin/ now). We’re thinking of better ways of enabling this, but the update lock is still the best mechanism for now.

The only alternative that might be useful is to use two separate apps, and always push to the other app and then [move](https://docs.resin.io/tools/cli/#device-move-60-uuid-62-) the devices to the other app when you want to trigger the update. (If you do this my recommendation is to not use the lock at all, as it’s been [known to cause trouble](https://github.com/resin-io/resin-supervisor/issues/348)).

If you stick to using the lock, it’s okay to keep the lock permanently, and doing it from the Dockerfile is fine. Using `touch` will probably work in your case as it would be unusual for the Supervisor to try to take the lock _immediately_ after starting the app - but it’s still safer if you use the method recommended by @imrehg. If it’s too complex to put inline in the CMD, you can always have a custom bash start script that does that (and starts your app), and use _that_ as the CMD.