This module provide utilities for managing “locks” on the lab-host. This can be used in setups where multiple users might try accessing the same host at the same time. Instead of cryptic errors due to busy devices or, even worse, bad behavior because of two running tbot testcases interfering, only one can ever access, for example, a board.
To facilitate this, two parts are needed:
The lab-host configuration must be augmented with the
LockManagermixin. This provides a locking “implementation” which board machines can hook into.
To enable locking for a certain board, it should inherit the
This is the initializer that is inherited by the board machine. It just calls the lab-host’s locking implementation.
lock_expiry: Optional[int] = None¶
Timeout after which the lock should be considered expired.
This provides a safeguard in case a testcase crashes without unlocking a lock - After the lock has expired, it will be considered unlocked again and a new testcase can acquire it.
Prefix from which lock file name is derived.
Defaults to the machine’s name:
Machine locking implementation based on Python, bash and flock(1)
lock_checkpid: bool = True¶
Make tbot check whether the PID associated with a lockfile is still alive.
If this check is enabled and the PID is found, the lock will be considered active, even if it would otherwise have been assumed expired.
The directory where tbot locks are stored.
/tmp/tbot-locks. If this directory does not exist, it will be created and given
0777access mode to allow all users to write lockfiles to it.
request_machine_lock(name: str, *, expiry: Optional[int] = None) → bool¶
Request lock for machine named
This method will usually be called via the
Trueif the lock has been acquired successfully and
release_machine_lock(name: str) → None¶
Release lock for machine named
If not explicitly released, the
LockManagerwill automatically unlock all locks it is holding when the lab-host machine is deinitialized.