On 4/20/20 1:07 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Apr 20, 2020 at 10:38:18AM +0300, Panu Matilainen wrote:
> On 4/17/20 5:09 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> On Fri, Apr 17, 2020 at 04:48:11PM +0300, Panu Matilainen wrote:
>>> On 3/26/20 1:32 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>>> On Thu, Mar 26, 2020 at 01:16:22PM +0200, Panu Matilainen wrote:
>>>>
>>>> Right. I realize %posttrans is not a good idea. But *some* mechanism
>>>> is necessary, because without that the change will mostly be a noop
>>>> for most users. So I think this needs to be decided somehow.
>>>>
>>> [...]
>>>> - 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.
>>>
>>> Looking at the details of how to do this now.
>>>
>>> The idea is to install a generic "rebuild rpmdb on boot" one-shot
>>> service, which can be flagged for action by 'touch
>>> /var/lib/rpm/.rebuilddb'. That would be done from rpm %posttrans
>>> when the rpmdb default changes, basically:
>>>
>>> '[ -f /var/lib/rpm/Packages ] && touch
/var/lib/rpm/.rebuilddb'
>>>
>>> Should it become necessary, the same mechanism can be used to
>>> convert back. This will of course trigger some "extra" rebuilds
for
>>> anybody staying on BDB backend but I'd say that's a feature...
>>
>> Shouldn't this be a one-time thing instead?
>> E.g. '%triggerpostun rpm < n.n.n-n', where n.n.n-n is the first
>> version with the changed default?
>
> Not really, because with a once in a lifetime opportunity there are
> too many ways things can go wrong. Also, we need to be herding
> people away from BDB with increasing intensity so even if we allow
> them to stay on BDB in F33
While I don't disagree with this assessment, doing the conversion each time
rpm is upgraded sounds wrong. I.e. if someone decides (for whatever reason)
to skip the update in F33, they shouldn't be badgered until F34 comes along.
When the switch is mandatory at some point (e.g. in F34), than we can
update the scriptlet to perform the upgrade unconditionally.
Basically, "allow them to stay on BDB in F33" and "try to perform the
upgrade
each time rpm.rpm is upgaded" seem incompatible.
Where does the service say anything about conversion? It merely rebuilds
the rpmdb, which is something BDB in particular will benefit from in two
ways: it restores performance, and fixes any unnoticed breakage from
indexes going out of sync. So it's a secret service being done to BDB
users ;) which will as a side-effect handle database conversions too.
>>> I'm thinking of something like this for
>>> /usr/lib/systemd/rpmdb-rebuild.service:
>>>
>>> ---
>>> [Unit]
>>> Description=RPM database rebuild
>>> ConditionPathExists=/var/lib/rpm/.rebuilddb
>>>
>>> [Service]
>>> Type=oneshot
>>> ExecStart=/usr/bin/rpmdb --rebuilddb
>>> ExecStartPost=rm -f /var/lib/rpm/.rebuilddb
>>>
>>> [Install]
>>> WantedBy=basic.target
>>
>> [Unit]
>> Description=RPM database rebuild
>> ConditionPathExists=/var/lib/rpm/.rebuilddb
>> DefaultDependencies=no
>> After=sysinit.target
>
> Should we also add Requires=sysinit.target I don't think we want
> this running on a boot where basics are failing...
Yes.
>> Before=basic.target shutdown.target
>> Conflicts=shutdown.target
>
> Hmm, what's with the shutdown.target This is not a service that will
> remain active so shutdown doesn't seem relevant.
Conflicts=shutdown.target is normally added to all units where
DefaultDependencies=no, to mimick the dependencies that would be added
by default. It ensures that the service is stopped before a shutdown.
It most cases it would not matter, but it's more correct to have it.
>> [Service]
>> Type=oneshot
>> ExecStart=rpmdb --rebuilddb
>> ExecStartPost=rm -f /var/lib/rpm/.rebuilddb
>>
>> [Install]
>> WantedBy=basic.target
>>
>> (Service units have default dependency on basic.target, so if this
>> is to be ordered before basic.target, it needs DefaultDependencies=no.)
>
> I guess the question is rather, is running before basic.target
> actually reasonable or even desireable? At the very least, we'd need
> to also add
>
> RequiresMountsFor=/var /var/tmp
>
> ...because obviously /var needs to be there for this. And that makes
> me wonder what else is missing that we'd need.
/var and /var/tmp would be ordered before local-fs.target, so the
dependency on sysinit.target should be enough to handle this.
For local /var yes, but basic.target has this:
# We support /var, /tmp, /var/tmp, being on NFS, but we don't pull in
# remote-fs.target by default, hence pull them in explicitly here. Note
that we
# require /var and /var/tmp, but only add a Wants= type dependency on
/tmp, as
# we support that unit being masked, and this should not be considered
an error.
RequiresMountsFor=/var /var/tmp
Wants=tmp.mount
Not that BDB rpmdb on NFS is supported, except for read-only mounts maybe...
- Panu -