On 3/26/20 4:08 PM, Zbigniew Jędrzejewski-Szmek wrote:
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 ;(
It *used to* replace files one by one before
https://github.com/rpm-software-management/rpm/commit/fffd652c56eaef8fc41d23190e39513639f2092d
Now it's just two rename() calls on directories, so it's worlds better
and the best we can do with portable system calls. So yes if you win the
unlucky lottery to have system reboot between those two rename() calls,
you can end up with having to manually rename it into place.
So to put that into perspective, --rebuilddb was *much* worse for over
twenty years and I've never heard anybodys database getting nuked
because of *that*.
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?
The places where rpm turns up never ceases to astonish me, starting from
OS X to FreeBSD to the old proprietory unixen (AIX was already
mentioned). There's even an actively maintained OS/2 port of rpm.
Seriously. To that, I had to mostly say no.
Of course, these things can be abstracted out in portable wrappers to
take advantage of newer and/or OS-specific features, but guess what,
that takes time and effort. As does replacing any code.
The *at() family was added in POSIX.1-2008, and time may finally be ripe
for rpm to start requiring them without having to paper over with
wrapper calls, but even then, somebody needs to do the work. We haven't
recently had any spare cycles to go chase looking for stuff that could
be maybe replaced with something newer just because its ... newer. I
don't recall a single rpm bug report that would've been avoided by use
of the *at() stuff, so there doesn't seem to be a whole lot of benefit.
Rewriting rpm's core file management operations for more robust error
handling has been in the todo for years. When that finally happens,
it'll be a good opportunity to take advantage of the newer interfaces.
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?
No.
- Panu -
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
_______________________________________________
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
