Hi,
what does yum make requiring a global lock for _every_ operation as root? I can search/info/download as normal user, while updating the system but not as root. Why that? Why do we need to lock yum for more than rpm transactions (shouldn't rpm do that at all) and cache write operations?
regards
christoph
On Tue, 2008-10-21 at 20:01 +0200, Christoph Höger wrote:
Hi,
what does yum make requiring a global lock for _every_ operation as root? I can search/info/download as normal user, while updating the system but not as root. Why that?
B/c none of the /var/cache/yum dir is writable as a user. But as root it is all writable. Changing the metadata while another yum operation is going on will result in unpredictable results.
Why do we need to lock yum for more than rpm transactions (shouldn't rpm do that at all) and cache write operations?
b/c we write out other data.
-sv
Would you be interested in making it more fine-grained at all? As its python I basically _could_ do some work.
Am Dienstag, den 21.10.2008, 14:37 -0400 schrieb seth vidal:
On Tue, 2008-10-21 at 20:01 +0200, Christoph Höger wrote:
Hi,
what does yum make requiring a global lock for _every_ operation as root? I can search/info/download as normal user, while updating the system but not as root. Why that?
B/c none of the /var/cache/yum dir is writable as a user. But as root it is all writable. Changing the metadata while another yum operation is going on will result in unpredictable results.
Why do we need to lock yum for more than rpm transactions (shouldn't rpm do that at all) and cache write operations?
b/c we write out other data.
-sv
ok, that sounds like some motivation for me do to it.
I've had a quick look over the source code and could not yet figure out, which functions really modify stuff in /var/cache/yum, but at a first glance it seem to be a few. You do not have a list of them flying around, don't you? ;)
My approach would be to create a decorator (called @needslock or something) and add it to every function that needs it. That decorator would look like the one in the attachment. Is that the yum-way fo doing it?
regards
Christoph
On Wed, 2008-10-22 at 17:47 +0200, Christoph Höger wrote:
ok, that sounds like some motivation for me do to it.
I've had a quick look over the source code and could not yet figure out, which functions really modify stuff in /var/cache/yum, but at a first glance it seem to be a few. You do not have a list of them flying around, don't you? ;)
Without thinking about it too long, the big problems are:
1. As soon as you open a repomd.xml for a repo. you need to make sure that repo. metadata doesn't change. dito. problems with two yum instances using the same repoid to mean different repos. IMO this should be fixed without adding locking (), but you could do it the locking way.
2. The package downloading isn't safe from multiple yums. 2b. Auto cleanup shouldn't delete stuff that was download by another yum instance :)
This _really_ needs to be done without locking, so background processes can start downloading lots of updates without killing the cmd line UI if it starts up.
3. plugins, like fastest mirror, assuming locking. Probably just audit/fix the plugins to not require locking.
4. Complete transaction/yum.log should be looked at.
5. Need to make sure we dtrt. wrt. yum not being locked by rpm being locked, this is true now ... but less tested.
My approach would be to create a decorator (called @needslock or something) and add it to every function that needs it. That decorator would look like the one in the attachment. Is that the yum-way fo doing it?
You can't do it this way, locking requirements aren't localized to specific functions ... if you want to go the locking route you'll have to add locks per. operation and take them when certain functions are run but only drop them when the repo/YumBase is deleted. You also need to make sure it doesn't deadlock.
On Wed, 2008-10-22 at 17:47 +0200, Christoph Höger wrote:
ok, that sounds like some motivation for me do to it.
I've had a quick look over the source code and could not yet figure out, which functions really modify stuff in /var/cache/yum, but at a first glance it seem to be a few. You do not have a list of them flying around, don't you? ;)
My approach would be to create a decorator (called @needslock or something) and add it to every function that needs it. That decorator would look like the one in the attachment. Is that the yum-way fo doing it?
If you want to talk about this more - please join yum-devel@lists.baseurl.org
fedora-devel is the wrong list for it.
thanks, -sv