A way to ensure rpm database robustness?
pmatilai at laiskiainen.org
Mon Jan 7 11:15:14 UTC 2013
On 01/03/2013 01:56 PM, Reshetova, Elena wrote:
> I have a simple question and sorry if it was asked before and I just didn't
> find it in archives.
> Suppose we run rpm operation (installation, update or anything) on an
> embedded device and power suddenly goes off. This can happen if user removes
> the battery for example.
> In such cases, rpm database can get corrupted since the operation was
> stopped in the middle. Rpm database can be rebuild after, but this is quite
> annoying to do. Is there any ways to ensure that database stays sane even in
> such cases? Of course some wrapper can be used for rpm to do the checks,
> backup database and etc., but does rpm itself have anything for it?
No, rpm currently has practically zero protection against such
scenarios, be it from accidentally tripping over the power cord, system
crash or pulling out the battery. Or even just executing 'shutdown -h now'.
Inconsistent database is just one part of the resulting mess: files or
partial files can be left around, scriptlets might have been executed
resulting in untrackable changes etc. And what happens if we were
executing a scriptlet while power went out is anybodys guess.
The database could be made to use transactions (its just a bit tricky in
presence of chroots) but that doesn't help the rest of the system. Rpm
would have to use write-ahead log mechanism for *everything* it does,
but even that wouldn't help the scriptlets aborted in mid-flight:
something like ldconfig might be safely repeatable from rpm POV but
ldconfig's ability to deal with malformed cache from getting interrupted
is up to ldconfig. And then take some more complex script that can do
arbitrary manipulation on various text and binary files...
The only sledgehammer that supposedly works for all these is
filesystem-level snapshots, but then that has its own issues.
- Panu -
More information about the Rpm-list