In the environment, INVOCATION_ID= will be set, when the process is executed under an invocation of a systemd unit. (This can also be reliably verified from the process keyring). When that is set, waitready, can check if said invocation _id is present on the current system's systemd by talking to /run/systemd/private. Then it could establish the watch on the main process of the matching invocation_id, if found. If all of above checks out, it means waitready can know for a fact that said invocation_id is what this waitready is blocked on. It can then establish a job status watch, and after establishing the watch to check if MAIN process has already died. By definition, waitready is spawned after the main process is spawned, so this should not be racy. Then waitready could receive the event that mainpid died, and bailout with an error earlier than the 10 minute timeout.
If something like that would be welcomed, I could work on a patch that does that inside the waitready function. Let me did my logs w.r.t. database stuff. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1765699 Title: lxd fails to start main process, yet waitready doesn't bail out To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1765699/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
