On 01/03/2013 01:56 PM, Reshetova, Elena wrote:
Hi, 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 - _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
