|Summary:||FC7 Pirut (and the others too)|
|Product:||[Fedora] Fedora||Reporter:||Leslie Satenstein <lsatenstein>|
|Component:||pirut||Assignee:||Jeremy Katz <katzj>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-06-07 12:53:31 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Leslie Satenstein 2007-06-01 03:42:25 UTC
Description of problem: No application lock between pirut, and yum. Results in pirut aborting because the program to be installed was installed a few minutes earlier then pirut arrived at attempting to do the same install. Result-- Pirut aborts. Version-Release number of selected component (if applicable): How reproducible: start pirut, then start yum Steps to Reproduce: 1. 2. 3. Actual results: Yum should not run if pirut is running, and vice versa. Expected results: Additional info: To remedy the problem, rpm -e rpm file that pirut wants to install, then restart pirut. There are other methods as well, but this is and safer one to do.
Comment 1 Leslie Satenstein 2007-06-01 21:00:17 UTC
Here is more clarification. I started Pirut, and almost right away, I started yum to do some installs that were not in the items selected for Pirut. However, with some common dependencies, yum achieved its install before pirut. When pirut arrived at the identical dependency, it borked, (A new word to replace soft abort). It is not a show stopper. It means we need to make pirut idiot proof. And I fall into the latter category.
Comment 2 Jeremy Katz 2007-06-04 20:09:40 UTC
They should both be taking /var/run/yum.pid as a lock file and checking to ensure that there's nothing else running. I just tried starting them in both orders without problems. Can you confirm that /var/run/yum.pid is getting created?
Comment 3 Leslie Satenstein 2007-06-05 03:33:43 UTC
Yes, but is / was there a race condition such that either yum or pirut started just before the other. I may have selected yum and also triggered pirut, or vice versa. Anyway, I did a no-no, and it happened. I don't expect to do this again.
Comment 4 Jeremy Katz 2007-06-05 15:11:25 UTC
Yeah, but in theory, before we do anything "real", we're taking the lock in both. And if taking the lock fails, then an exception gets raised leading to either a dialog and exiting in pirut or an error message on the command line in yum. I'll try adding some sleeps in places to try to make it easier to reproduce, but just generally trying, I get the expected behavior
Comment 5 Leslie Satenstein 2007-06-07 12:53:31 UTC
I just have to use common sense and the "race" problem will be no more. Thank you for the update. Here is another issue (off topic). I have 2 hard drives with 2 fedora 7 systems. (/dev/sda) with 32 bit fedora and /dev/sdb with 64 bit fedora. Pirup, when I boot from the bios setting for the 64 bit system, also ends up copying in 32 bit code. I dont know if this was intended or just poor filtering. I manually dropped the 32 bit code after execution by using yumex, and nothing that I deleted caused fedora to break.