Description of problem: Since pthreading 0.1.3, we monkey patch also the thread module. This requires that the thread module is imported before importing the threading module, and this is indeed what pthreading does. However, since vdsm does not import pthreading before all other modules, we monkey patch the thread module too late, after other modules have accessed it. The effect is having both pthreading and threading locks in the same system, which is the behavior of pthreading 0.1.2. This problem is fixed in upstream and ovirt-3.5. Version-Release number of selected component (if applicable): vdsm-4.14.0 How reproducible: Always
[root@slot-7 ~]# rpm -ql vdsm | xargs grep -n monkey /usr/share/vdsm/vdsm:13:# When using Python 2, we must monkey patch threading module before importing /usr/share/vdsm/vdsm:17: pthreading.monkey_patch() grep: /var/run/vdsm/payload: No such file or directory [root@slot-7 ~]# rpm -qa vdsm vdsm-4.14.13-1.el6ev.x86_64
If this bug requires doc text for errata release, please provide draft text in the following format: Cause: Consequence: Fix: Result: The documentation team will review, edit, and approve the text. If this bug does not require doc text, please set the 'requires_doc_text' flag to -. Thanks.
(In reply to Lucinda Bopf from comment #3) Cause: vdsm import pthreading module after importing threading module. Consequence: The effect is having both pthreading and threading locks in the same system, which is the behavior of pthreading 0.1.2. When using newer version of pthreading, vdsm will fail to start, since pthreading pthreading.monkey_patch() raises an exception if it is too late. Fix: Vdsm import pthreading before any other module that may import the threading module. Result: pthreading modify threading module correctly, and when using newer versions of pthreading, vdsm will not fail to start.
Lucinda, the doc text is not correct - it seems that you do not understand the issue. Please use the suggested text from comment 4. The suggested text may need some polish, but it is technically correct.
Why does this BZ require doctext? Was it ever visible to customers?
(In reply to Allon Mureinik from comment #6) > Why does this BZ require doctext? > Was it ever visible to customers? I think it was visible for few days while pthreading 0.1.3-1 was out, before it was replaced by 0.1.3-3. So maybe we can skip the doc text for this.
(In reply to Nir Soffer from comment #7) > (In reply to Allon Mureinik from comment #6) > > Why does this BZ require doctext? > > Was it ever visible to customers? > > I think it was visible for few days while pthreading 0.1.3-1 was out, before > it was replaced by 0.1.3-3. > > So maybe we can skip the doc text for this. This was never visible to RHEV customers (as opposed to oVirt developers). And considering the fact that from a user's perspective the doctext boils down to "a developer made a mistake and VDSM gets stuck in seemingly random points). I think we can live without it.
Nir, Allon, Since this bug no longer requires doc text, and the text I had entered appears to be not technically correct, I will remove the text altogether. This will ensure that the text does not confuse anyone else who views this bug. Lucy
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1152.html