ExternalVendorCode/balena-supervisor
1
0
Fork 0
mirror of https://github.com/balena-os/balena-supervisor.git synced 2024-12-24 07:46:41 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

docs: Clarify update locks for multicontainer applications

Browse Source 
Change-type: patch
Signed-off-by: Gareth Davies <gareth@balena.io>
This commit is contained in:
Gareth Davies 2020-03-16 14:09:28 -07:00
parent c37079188f
commit a6b0c50d8e
No known key found for this signature in database
GPG Key ID: E8E74ABF2E724C82
1 changed files with 2 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/update-locking.md
View File

@ -9,6 +9,8 @@ Locking updates means that the balena supervisor will not be able to kill your a
In order to do this, users can create a lockfile in a way that it has exclusive access, which will prevent the device supervisor from killing and restarting the app. As with any other lockfile, the supervisor itself will create such a file before killing the app, so you should only create it in exclusive mode. This means that the lockfile should only be created if it doesn't already exist. The exclusive access is achieved by opening the lockfile with the [O_EXCL and O_CREAT flags](https://linux.die.net/man/3/open), and several tools exist to simplify this process with examples given [below](#creating-the-lockfile).
For multicontainer applications, a release will only be updated if all of the services can be updated. While locks are per-service, having the update lock in a single service will prevent all services from updating to a new release.
The presence of a lockfile will ensure that your application does not get killed, but updates will still be downloaded by the supervisor, ready to be applied once the lockfile no longer exists.
### Location of the lockfile