On Thu, Mar 26, 2020 at 8:22 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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(a)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/fffd652c56eaef8fc41...
--
真実はいつも一つ!/ Always, there's only one truth!