| Message ID | 20250303130628.1656131-2-richard.purdie@linuxfoundation.org |
|---|---|
| State | Accepted, archived |
| Commit | a9eb8bf7174b6962b5ba07192fe95b8c7112d9d2 |
| Headers | show |
| Series | [1/4] utils: Print information about lock issue before exiting | expand |
On Mon, Mar 3, 2025 at 6:06 AM Richard Purdie via lists.openembedded.org <richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote: > > We should really try and take the lock in the try/finally block so that > in some rare cases such as badly timed interrupt/signal, we always release > the lock. > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> > --- > lib/bb/utils.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/bb/utils.py b/lib/bb/utils.py > index da8c20fe95..992e200641 100644 > --- a/lib/bb/utils.py > +++ b/lib/bb/utils.py > @@ -1881,8 +1881,8 @@ def path_is_descendant(descendant, ancestor): > # we exit at some point than hang. 5 minutes with no progress means we're probably deadlocked. > @contextmanager > def lock_timeout(lock): > - held = lock.acquire(timeout=5*60) > try: > + held = lock.acquire(timeout=5*60) If lock.acquire() raises an exception, then the `finally` will fail because `held` is not defined, so I'm not sure this is correct > if not held: > bb.server.process.serverlog("Couldn't get the lock for 5 mins, timed out, exiting.\n%s" % traceback.format_stack()) > os._exit(1) > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#17370): https://lists.openembedded.org/g/bitbake-devel/message/17370 > Mute This Topic: https://lists.openembedded.org/mt/111487227/3616693 > Group Owner: bitbake-devel+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/bitbake-devel/unsub [JPEWhacker@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
diff --git a/lib/bb/utils.py b/lib/bb/utils.py index da8c20fe95..992e200641 100644 --- a/lib/bb/utils.py +++ b/lib/bb/utils.py @@ -1881,8 +1881,8 @@ def path_is_descendant(descendant, ancestor): # we exit at some point than hang. 5 minutes with no progress means we're probably deadlocked. @contextmanager def lock_timeout(lock): - held = lock.acquire(timeout=5*60) try: + held = lock.acquire(timeout=5*60) if not held: bb.server.process.serverlog("Couldn't get the lock for 5 mins, timed out, exiting.\n%s" % traceback.format_stack()) os._exit(1)
We should really try and take the lock in the try/finally block so that in some rare cases such as badly timed interrupt/signal, we always release the lock. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> --- lib/bb/utils.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)