--- Begin Message ---
On 2025-03-24 17:02, Thomas Lamprecht wrote:
Am 22.03.25 um 16:17 schrieb Jing Luo:
It's more appropriate under Debian, and vzdump.lock doesn't seem to
be used by any other package.
This is very dangerous and needs a ton of work to be done right.
As any vzdump job that started before a package update got installed
that
includes this (and the others) patches and any job started afterwards
will
not be protected at all.
My bad, for this patch I didn't think it through what the result could
be. For
now let's drop this patch.
Same for all other patches and the respective things they use the lock
to protect against mutual access.
If this was done we would need to:
- keep the old lock path for one major release around and always
acquire
the lock over the old path first for as long as we can safely say
that
no old job is running. For a lot of things this means until the next
reboot, as /run is tmpfs backed and thus will be cleared then anyway.
- need some actual good reason instead of "it's more appropriate" which
can be a fine argument for adding new lock paths but definitively not
enough to justify moving existing ones.
The same holds for all patches of this series.
What's wrong with other patches in the series? No lock file path is
moved, b/c
/var/run is a symlink to /run and /var/lock is a symlink to /run/lock,
unless
we have to account for non-Debian systems where /var/run and /var/lock
are not
symlinks?
--
Jing Luo
About me: https://jing.rocks/about/
GPG Fingerprint: 4E09 8D19 00AA 3F72 1899 2614 09B3 316E 13A1 1EFC
signature.asc
Description: OpenPGP digital signature
--- End Message ---
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
