Am 30/01/2024 um 18:10 schrieb Friedrich Weber: > Previously, container start/stop/shutdown/suspend would try to acquire > the config lock in the API handler prior to forking a worker. If the > lock was currently held elsewhere, this would block the API handler > and thus the pvedaemon worker thread until the 10s timeout expired (or > the lock could be acquired). > > To avoid blocking the API handler, immediately fork off a worker > process and try to acquire the config lock in that worker. > > Patch best viewed with `git show -w`. > > Suggested-by: Wolfgang Bumiller <w.bumil...@proxmox.com> > Signed-off-by: Friedrich Weber <f.we...@proxmox.com> > --- > > Notes: > The diff is somewhat messy without `-w` -- couldn't come up with a > better way. > > new in v2 > > src/PVE/API2/LXC/Status.pm | 91 ++++++++++++++++++-------------------- > 1 file changed, 42 insertions(+), 49 deletions(-) > >
applied this one already, thanks! btw. in general getting some early timeout sent as response to the initial request would be good, but blocking the daemon worker is naturally a no-go. And bringing in Anyevent somehow to make it async-like might be a PITA, so for now this change is OK. Oh, and it might be worth mentioning explicitly in the next release notes, as it's a change in behavior that could theoretically throw up some tooling that depends on the $action not failing due to locking if the adapted endpoints returned – albeit IMO a bit silly to assume that (as the actions can fail in other ways inside the worker anyway). _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
