[Twisted-Python] PotentialZombieWarning warning message?
Hi: I'd like to adopt Twisted for a current project I'm coding up. I'm on CentOS 6.7 x86-64 using python v2.6 and the stock python-twisted-8.2.0-3.1 package built for this release. No matter what I do when trying to implement the Process protocol or use utils.getProcessOutput() directly, I always see the following warning message on the console: /usr/lib64/python2.6/site-packages/twisted/internet/utils.py:25: PotentialZombieWarning: spawnProcess called, but the SIGCHLD handler is not installed. This probably means you have not yet called reactor.run, or called reactor.run(installSignalHandler=0). You will probably never see this process finish, and it may become a zombie process. reactor.spawnProcess(p, executable, (executable,)+tuple(args), env, path) ... Is there anyway to get rid of this message? I realize I'm using an older release of twisted but I can't upgrade to the latest without incurring the cost of installing an python v2.7 or greater. My script is literally: d = utils.getProcessOutput('/bin/ls') d.addCallbacks(writeResponse, noResponse) reactor.run() etc. What am I doing wrong? -aps
...
Hi, Python 2.6 has been EOL for years and Twisted 8.2.0 is nearly seven years old. We can't really help with things that old (many, many issues have since been fixed, so remembering what's a bug that's been squashed and what's a platform bug is nearly impossible), but upgrading to Twisted 15.4 (the last release with Python 2.6 support, and only 4 or so months old) may help. - Amber
On Mon, Dec 14, 2015 at 10:09 AM, Amber "Hawkie" Brown <hawkowl@atleastfornow.net> wrote:
That maybe, but CentOS 6.7 is the latest 6.x release which ships with 8.2.x (somebody maintaining the RHEL 6.x series should update these packages then). I did a pip install and it said I needed Python 2.7 or higher. Let me reevaluate if I can just update twisted. Thanks! -aps
Try `pip install twisted==15.4´ if you still require Python2.6 support; `pip install twisted´ will install the latest, which no longer works on 2.6. But again: Python 2.6 is unsupported by the upstream Python developers. You really should not be using it, since it won't receive security updates (of course, Red Hat and transitively CentOS claim to "support" these packages, but if upstream is refusing patches at this point, it's not clear where that support will come from). This is why we changed our policy to proactively disable it: it's a security risk and we would like to put pressure on downstreams (such as yourself) to stop taking on this risk without realizing it. If you must use CentOS 6, then I'd recommend installing PyPy 4.0 from https://github.com/squeaky-pl/portable-pypy#portable-pypy-distribution-for-l... <https://github.com/squeaky-pl/portable-pypy#portable-pypy-distribution-for-l...> and using that. In addition to being security-supported, it will also make your python code run 10x faster :). -glyph
Great! Glad to hear you were able to make a huge leap in Twisted versions with little trouble :-).
I understand that things like this often do, which is exactly why I want to make it clear that we (speaking in terms of the broader Python community now, not just Twisted) are trying to push people towards more recent versions just because they're more fun or more aesthetically pleasant, but because there are very real risks associated with being on unsupported ancient versions of things. It pains me not to be supporting a configuration that some users want, but there is a line where "conservative about change" becomes "negligent about maintenance" and python 2.6 crossed it a little over two years ago :-).
Hope that works out for you. Good luck! -glyph
On Mon, Dec 14, 2015 at 7:43 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
I'm not disagreeing with you per se...but... The fact is the Python community at large then needs to convince the distro maintainers accordingly. Telling a customer to update their entire platform for a newer version of Python isn't going to fly a lot of times (and remember, someone of them have support agreements with RH). And running two versions of Python can get messy real fast. Anyway, it is what it is.
Thanks! So far, so good. I was now able to lift my prototype code and integrate it with the rest. I'll probably have more questions at some point, but at least 15.4 did the trick! -aps
"pisymbol ." <pisymbol@gmail.com> writes:
The community has. However Redhat has customers that want support for old systems and are willing to pay for it. CentOS is essentially a repackaged unsupported version of Redhat Enterprise Linux. If you want support for packages against an old version of python, you can contact Redhat (as per this[1] post by core python developer and Redhat employee). Tom [1] http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html
There is a solution to this, and Nick Coghlan has mentioned it to me many times -- Software Collections for RHEL and CentOS. Software Collections is RH's answer to "new software" on "stable distributions" -- SCLs operate side-by-side with system packages, so it won't break anything. Since you're a CentOS 6.7 user, the standard SCL should work (it's 6.5+). You can find the Python 2.7 SCL at https://www.softwarecollections.org/en/scls/rhscl/python27/, and CentOS publishes instructions on using them on https://wiki.centos.org/AdditionalResources/Repositories/SCL . This might solve your problem of being restrained to CentOS 6, but Python 2.6 being EOL'd everywhere but it. - Amber
Sorry if the quoting is a little weird in this, I've long since deleted Glyph's original response, so I'm replying to Amber's latest, but I just noticed something in the quote (from Glyph, I think) that I want to correct for the sake of posterity: pleasant, but because there are very real risks associated with being on unsupported ancient versions of things. It pains me not to be supporting a configuration that some users want, but there is a line where "conservative about change" becomes "negligent about maintenance" and python 2.6 crossed it a little over two years ago :-). I'm sure you meant "[we] are trying to push people towards more recent versions [NOT] just because they're more fun..." -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539
On 15/12/15 04:16, Amber "Hawkie" Brown wrote:
I really disliked the SCLs when I looked at it. The supported use-case seems to be a kind of hugely over-engineered set of wrapper/environment setup scripts: scl enable python2.7 pip install blah ...ad infinitum. Personally - and I guess for others as well - the SCLs will be off-putting. It's a shame there isn't a simpler solution, namely EPEL python2.7 - having a 2nd python in a different path is quite safe, we do it routinely. It's hugely annoying that RHEL6 and derivatives missed out on Python 2.7 :o(
We have a fair bit of Python 2.7 Twisted code deployed on RHEL and CentOS 5 and 6. In each case, we build from source and do a make altinstall so we’re running a Python separate from the system’s. Just takes a few minutes to get everything installed and running. On Tue, Dec 15, 2015 at 6:30 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
-- Raymond Cote, President voice: +1.603.924.6079 email: rgacote@AppropriateSolutions.com skype: ray.cote
Here (NASA/GSFC) we use conda-based virtual envs on CentOS 6, and they work great -- I turned our sysadmins on to conda about a year ago, and they *love* it (no more compiling python, woo! ;) All recent versions of twisted are available as conda packages: # conda search twisted Fetching package metadata: ...... twisted 12.3.0 py27_0 defaults 12.3.0 py26_0 defaults 13.0.0 py27_0 defaults 13.0.0 py26_0 defaults 13.1.0 py27_0 defaults 13.1.0 py26_0 defaults 13.2.0 py27_0 defaults 13.2.0 py26_0 defaults 14.0.0 py27_0 defaults 14.0.0 py26_0 defaults 14.0.2 py27_0 defaults 14.0.2 py26_0 defaults 15.0.0 py27_0 defaults 15.0.0 py26_0 defaults 15.1.0 py27_0 defaults 15.1.0 py26_0 defaults 15.2.0 py34_0 defaults 15.2.0 py27_0 defaults 15.2.0 py26_0 defaults 15.2.1 py34_0 defaults . 15.2.1 py27_0 defaults 15.2.1 py26_0 defaults 15.3.0 py34_0 defaults 15.3.0 py27_0 defaults 15.3.0 py26_0 defaults 15.4.0 py35_0 defaults 15.4.0 py34_0 defaults 15.4.0 py27_0 defaults 15.5.0 py35_0 defaults 15.5.0 py34_0 defaults * 15.5.0 py27_0 defaults Steve On 12/15/2015 11:40 AM, Ray Cote wrote:
On 15/12/2015 16:40, Ray Cote wrote:
We build an RPM, but basically yes; put it in a different path and it's fine. Minor hassle though it is, it's one more thing that I would prefer to not need. But reinstalling upwards of 60 RHEL6 production machines is vastly more hassle ;o)
...
Hi, Python 2.6 has been EOL for years and Twisted 8.2.0 is nearly seven years old. We can't really help with things that old (many, many issues have since been fixed, so remembering what's a bug that's been squashed and what's a platform bug is nearly impossible), but upgrading to Twisted 15.4 (the last release with Python 2.6 support, and only 4 or so months old) may help. - Amber
On Mon, Dec 14, 2015 at 10:09 AM, Amber "Hawkie" Brown <hawkowl@atleastfornow.net> wrote:
That maybe, but CentOS 6.7 is the latest 6.x release which ships with 8.2.x (somebody maintaining the RHEL 6.x series should update these packages then). I did a pip install and it said I needed Python 2.7 or higher. Let me reevaluate if I can just update twisted. Thanks! -aps
Try `pip install twisted==15.4´ if you still require Python2.6 support; `pip install twisted´ will install the latest, which no longer works on 2.6. But again: Python 2.6 is unsupported by the upstream Python developers. You really should not be using it, since it won't receive security updates (of course, Red Hat and transitively CentOS claim to "support" these packages, but if upstream is refusing patches at this point, it's not clear where that support will come from). This is why we changed our policy to proactively disable it: it's a security risk and we would like to put pressure on downstreams (such as yourself) to stop taking on this risk without realizing it. If you must use CentOS 6, then I'd recommend installing PyPy 4.0 from https://github.com/squeaky-pl/portable-pypy#portable-pypy-distribution-for-l... <https://github.com/squeaky-pl/portable-pypy#portable-pypy-distribution-for-l...> and using that. In addition to being security-supported, it will also make your python code run 10x faster :). -glyph
Great! Glad to hear you were able to make a huge leap in Twisted versions with little trouble :-).
I understand that things like this often do, which is exactly why I want to make it clear that we (speaking in terms of the broader Python community now, not just Twisted) are trying to push people towards more recent versions just because they're more fun or more aesthetically pleasant, but because there are very real risks associated with being on unsupported ancient versions of things. It pains me not to be supporting a configuration that some users want, but there is a line where "conservative about change" becomes "negligent about maintenance" and python 2.6 crossed it a little over two years ago :-).
Hope that works out for you. Good luck! -glyph
On Mon, Dec 14, 2015 at 7:43 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
I'm not disagreeing with you per se...but... The fact is the Python community at large then needs to convince the distro maintainers accordingly. Telling a customer to update their entire platform for a newer version of Python isn't going to fly a lot of times (and remember, someone of them have support agreements with RH). And running two versions of Python can get messy real fast. Anyway, it is what it is.
Thanks! So far, so good. I was now able to lift my prototype code and integrate it with the rest. I'll probably have more questions at some point, but at least 15.4 did the trick! -aps
"pisymbol ." <pisymbol@gmail.com> writes:
The community has. However Redhat has customers that want support for old systems and are willing to pay for it. CentOS is essentially a repackaged unsupported version of Redhat Enterprise Linux. If you want support for packages against an old version of python, you can contact Redhat (as per this[1] post by core python developer and Redhat employee). Tom [1] http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html
There is a solution to this, and Nick Coghlan has mentioned it to me many times -- Software Collections for RHEL and CentOS. Software Collections is RH's answer to "new software" on "stable distributions" -- SCLs operate side-by-side with system packages, so it won't break anything. Since you're a CentOS 6.7 user, the standard SCL should work (it's 6.5+). You can find the Python 2.7 SCL at https://www.softwarecollections.org/en/scls/rhscl/python27/, and CentOS publishes instructions on using them on https://wiki.centos.org/AdditionalResources/Repositories/SCL . This might solve your problem of being restrained to CentOS 6, but Python 2.6 being EOL'd everywhere but it. - Amber
Sorry if the quoting is a little weird in this, I've long since deleted Glyph's original response, so I'm replying to Amber's latest, but I just noticed something in the quote (from Glyph, I think) that I want to correct for the sake of posterity: pleasant, but because there are very real risks associated with being on unsupported ancient versions of things. It pains me not to be supporting a configuration that some users want, but there is a line where "conservative about change" becomes "negligent about maintenance" and python 2.6 crossed it a little over two years ago :-). I'm sure you meant "[we] are trying to push people towards more recent versions [NOT] just because they're more fun..." -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539
On 15/12/15 04:16, Amber "Hawkie" Brown wrote:
I really disliked the SCLs when I looked at it. The supported use-case seems to be a kind of hugely over-engineered set of wrapper/environment setup scripts: scl enable python2.7 pip install blah ...ad infinitum. Personally - and I guess for others as well - the SCLs will be off-putting. It's a shame there isn't a simpler solution, namely EPEL python2.7 - having a 2nd python in a different path is quite safe, we do it routinely. It's hugely annoying that RHEL6 and derivatives missed out on Python 2.7 :o(
We have a fair bit of Python 2.7 Twisted code deployed on RHEL and CentOS 5 and 6. In each case, we build from source and do a make altinstall so we’re running a Python separate from the system’s. Just takes a few minutes to get everything installed and running. On Tue, Dec 15, 2015 at 6:30 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
-- Raymond Cote, President voice: +1.603.924.6079 email: rgacote@AppropriateSolutions.com skype: ray.cote
Here (NASA/GSFC) we use conda-based virtual envs on CentOS 6, and they work great -- I turned our sysadmins on to conda about a year ago, and they *love* it (no more compiling python, woo! ;) All recent versions of twisted are available as conda packages: # conda search twisted Fetching package metadata: ...... twisted 12.3.0 py27_0 defaults 12.3.0 py26_0 defaults 13.0.0 py27_0 defaults 13.0.0 py26_0 defaults 13.1.0 py27_0 defaults 13.1.0 py26_0 defaults 13.2.0 py27_0 defaults 13.2.0 py26_0 defaults 14.0.0 py27_0 defaults 14.0.0 py26_0 defaults 14.0.2 py27_0 defaults 14.0.2 py26_0 defaults 15.0.0 py27_0 defaults 15.0.0 py26_0 defaults 15.1.0 py27_0 defaults 15.1.0 py26_0 defaults 15.2.0 py34_0 defaults 15.2.0 py27_0 defaults 15.2.0 py26_0 defaults 15.2.1 py34_0 defaults . 15.2.1 py27_0 defaults 15.2.1 py26_0 defaults 15.3.0 py34_0 defaults 15.3.0 py27_0 defaults 15.3.0 py26_0 defaults 15.4.0 py35_0 defaults 15.4.0 py34_0 defaults 15.4.0 py27_0 defaults 15.5.0 py35_0 defaults 15.5.0 py34_0 defaults * 15.5.0 py27_0 defaults Steve On 12/15/2015 11:40 AM, Ray Cote wrote:
On 15/12/2015 16:40, Ray Cote wrote:
We build an RPM, but basically yes; put it in a different path and it's fine. Minor hassle though it is, it's one more thing that I would prefer to not need. But reinstalling upwards of 60 RHEL6 production machines is vastly more hassle ;o)
participants (8)
-
Amber "Hawkie" Brown -
Glyph Lefkowitz -
John Santos -
Phil Mayers -
pisymbol . -
Ray Cote -
Steve Waterbury -
Tom Prince