(PUP-1775) Acquire and block for Yum's lock to prevent corruption#2473
(PUP-1775) Acquire and block for Yum's lock to prevent corruption#2473domcleal wants to merge 2 commits intopuppetlabs:masterfrom
Conversation
Yum tools always attempt to acquire a global lock to prevent database corruption by blocking. This change adds lock acquisition to the yumhelper which is called by the yum package provider, looping until either a timeout is reached or the lock acquisition was successful.
|
Should we rip out |
|
CLA signed by all contributors. |
|
@kylog interesting idea, it'd certainly reduce risk of yumhelper going wrong. RHEL3 has been EOL for some time, so I think this would be fine. The other thing I was thinking of was to start logging bugs against it, but I wouldn't be in a particular hurry to fix it. |
The yumhelper had two paths of code - either it could load the yum library and would use this to enumerate the updates, or it would call `yum check-update` and parse the output. The latter was typically used on very old versions of Yum (i.e. RHEL3 era) which have long been EOL. To simplify this code, the shell fallback method has been removed. Failures to load the library will result in the script raising an error.
|
@kylog sorry for the delay. I've updated the PR to remove the legacy code. |
|
@domcleal to check, you've been able to validate this code for yourself that this works as expected? |
|
@adrienthebo yes, I tested using a "sleeper" RPM (which I attached to PUP-1775) to verify that when the sleeper RPM is being installed and you run Puppet in parallel that the prefetching through yumhelper pauses until the lock is fetched. I've only tested on RHEL 6 x86_64. |
|
Awesome, thanks for verifying this! With luck we'll have this merged shortly. |
There was a problem hiding this comment.
This is far longer than we should wait while trying to install a package, I think this should be closer to 10 seconds. If we can't retrieve this information then we should fail hard.
|
@domcleal the more I look at this, the more nervous I get about using the yum python bindings. I checked the version of yum back to CentOS 4 and |
There was a problem hiding this comment.
@domcleal do we want to unlock first, then close (in reverse order that those were acquired)?
There was a problem hiding this comment.
No, that would be wrong. This patch acquires the yum lock, the rpm db is then implicitely opened later in the middle of the yum guts. You need to close tht db first, before unlocking yum.
|
@adrienthebo My concern was only that this was the original implementation, and that it was changed to the python helper by @lutter in response to a change in behaviour. As you said, it hasn't changed again recently so probably would be OK to switch back. I'm not likely to have time to implement this though, sorry. The ancient bug http://projects.puppetlabs.com/issues/836 has some information. It looks like the provider switched to prefetching in the same commit (8722e43), so the original issue about calling "yum list available" for a package without an update available is actually moot (see comment in http://projects.puppetlabs.com/attachments/175/yum.patch). |
|
This is superseded by GH-2670 which removes yumhelper.py in favor of parsing the output of |
6 participants
Yum tools always attempt to acquire a global lock to prevent database
corruption by blocking. This change adds lock acquisition to the yumhelper
which is called by the yum package provider, looping until either a timeout
is reached or the lock acquisition was successful.
Replaces #2387