On Thu, Mar 26, 2020 at 8:22 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Thu, Mar 26, 2020 at 07:38:33AM -0400, Neal Gompa wrote:
On Thu, Mar 26, 2020 at 7:33 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
- a one-shot service: this is easier to implement, it just needs to happen in one place. The hard part is making sure that the machine does not get reboot while the upgrade is happening. This is in particular a problem with VMs and containers. The rebuild should be wrapped with systemd-inhibit and other guards to make it hard to interrupt.
Wouldn't the systemd-inhibit plugin automatically ensure that a rebuild action would block sleep/poweroff?
Unfortunately... not. From the man page: inhibitors "may be used to block or delay system sleep and shutdown requests from the user, as well as automatic idle handling of the OS." Explicit non-interactive privileged requests override inhibitors [1,2]. This has been discussed, and I think there's general sentiment that we should have an ability to inhibit "everything", but so far nobody has pushed for a solution. A solution could be proritized if it turns out to be required in Fedora.
[1] https://github.com/systemd/systemd/issues/2680 [2] https://github.com/systemd/systemd/issues/6644
I'm not sure it's needed with rpm 4.14+, since worst case is that you have to trigger the rebuild some other time if it's interrupted.
No matter how it wrapped, is the upgrade itself atomic? Having the new db built under a temporary file name and then atomically rename(2)d into place would be ideal.
Since RPM 4.14, RPM creates a new directory, writes the database content there, then renames the directory when it's done.
Does it use renameat2(RENAME_EXCHANGE)?
No, but I don't think that matters with the way it's implemented?
See: https://github.com/rpm-software-management/rpm/commit/fffd652c56eaef8fc41d23...
-- 真実はいつも一つ！/ Always, there's only one truth!