Backport a Python issue13146 to Python 2.7 on EL 7

Latest response

This bug causes mysterious, nondeterministic crash of Python applications.
https://bugs.python.org/issue13146
Writing a pyc file is not atomic

The Python 2.7 patch https://bugs.python.org/file30324/13146-2.7.patch works fine.

It would help if we could backport it to the Python 2.7 in the upcoming EL 7.5 release.

Nice to have another patch that fixes a selftest failure too. https://bugs.python.org/issue31158: read returns 5 bytes only.

Thanks.

JW
Log in to join the conversation

Responses

Jamie Bainbridge's picture Red Hat Guru 7257 points
11 November 2017 2:04 AM

I logged bugs against the EL7 python component for you:

  • Red Hat Private Bug 1512159 - python: Writing a pyc file is not atomic
  • Red Hat Private Bug 1512160 - python: test_pty: test_basic() fails randomly on Travis CI

If you have a Red Hat Bugzilla account, let me know it and I'll add you to the bug CC, or I can just report back any updates here.

JW Community Member 20 points
11 November 2017 6:37 AM

I do have a Redhat Bugzilla account, which is a personal email address. How can I privately send you the email address?

Jamie Bainbridge's picture Red Hat Guru 7257 points
12 November 2017 10:57 PM

Email it to techsupport@redhat.com with "Attn: Jamie Bainbridge" in the subject line.

CS Red Hat Newbie 5 points
15 November 2017 3:40 PM

Hello and thanks for your report.

While that specific issue was fixed in python3, the same fix was deemed too intrusive for python2 by upstream.

Also as soon as this issue was introduced in python3 some things broke (see https://bugs.python.org/issue17222 ) and from the RHEL perspective, we need to be really careful with making any changes that might break use cases/setups/code etc that relied on the previous behaviours, even implicitly.

From a higher level overview, code which brings python2 closer to python3's behaviour can introduce unexpected regressions, as it has happened in the past.

What is the severity of the issue and what is your use case?

In regards to the failure of test_pty, that is a reasonable request and will be evaluated, since it will make the python builds fail randomly and it can disrupt workflows and CI infrastructures for anyone who rebuilds from source.

JW Community Member 20 points
15 November 2017 6:04 PM

The severity of this issue is very high in Twitter private cloud environment running Mesos/Aurora. Usually within a month of running Python without this patch, Python bytecode cache will be corrupted on many random hosts in the cluster -- leading to crash of many OTHER unrelated Python applications. The tricky part is that the application crashed isn't the one who caused the bytecode cache corruption and it is hard to track down which application had caused the crash under what use cases. The only way to cleanly recover from the problem is to re-kickstart/reinstall/re-image those hosts.

Since December 2016, developers had to manually patch the RHEL Python with this fix for every OS 7 upgrade. There hasn't been any regression observed with this patch in the same running environment.

pv Red Hat Newbie 5 points
27 November 2017 10:35 AM

From the Python point of view, best practice would be pre-compiling the .pyc files (e.g. with python -m compileall), and shipping them with the code. Automatic compiling/caching is nice for development, but if you're at the point of deploying to multiple hosts, compile once for all of them. This might not work for one-off scripts; there you might want to set PYHTONDONTWRITEBYTECODE as a workaround.

JW Community Member 20 points
13 December 2017 8:29 AM

In a multi-tenancy cloud environment, on any given host, various different applications are dynamically scheduled to run there. Application code packages are also dynamically deployed on-demand. Shipping the pre-compiled .pyc file would increase package size.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.