On Thu, Mar 26, 2020 at 08:44:47AM -0400, Neal Gompa wrote: > On Thu, Mar 26, 2020 at 8:22 AM Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> 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@xxxxxxxxx> 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/fffd652c56eaef8fc41d23190e39513639f2092d I think otherwise it'd be hard to do an atomic replacement when the database consists of more than one file. But looking at the code: xx = rename(dest, old); if (xx) { goto exit; } xx = rename(src, dest); (dest, src, old are all single-file paths) if I'm reading this correctly, it doesn't even to atomic replacement of individual files. If the machine is rebooted between the two renames above, no database ;( On Thu, Mar 26, 2020 at 03:29:50PM +0200, Panu Matilainen wrote: > No, rpm doesn't use many Linux-specific calls and this is no > exception. In fact it doesn't use any of the *at() family calls > directly either. But why?! It's not like rpm is massive on Windows Server... Isn't good support for Linux absolutely the most important thing? > This is actually the first I hear about that system call which > indeed seems highly useful for rpm, so thanks for the tip :) So... does this mean that we can get #61413 a.k.a. #447156 resolved? Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
