Bug#985818: unblock: swift/2.26.0-9
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: unblock
Please unblock package swift
There's 2 changes. First, python3-dnspython is added as recommends, otherise
without it, the cname_lookup module of swift wouldn't work. But that's the
least important change.
The 2nd change is a patch from upstream, which avoids the swift processes to
fall into deadlocks. We experienced it in production, and that's not fun,
and it's also very hard to understand what's happening. I would really like
to have the patch included in Bullseye.
Debdiff attached.
Please unblock swift/2.26.0-9
Cheers,
Thomas Goirand (zigo)
diff -Nru swift-2.26.0/debian/changelog swift-2.26.0/debian/changelog
--- swift-2.26.0/debian/changelog 2021-02-23 14:11:16.000000000 +0100
+++ swift-2.26.0/debian/changelog 2021-03-24 10:12:53.000000000 +0100
@@ -1,3 +1,11 @@
+swift (2.26.0-9) unstable; urgency=medium
+
+ * Add python3-dnspython as Recommends for the proxy, as this is needed for
+ the cname_lookup middleware.
+ * Add Turn_off_logging.logThreads_when_monkey-patched.patch.
+
+ -- Thomas Goirand <zigo@debian.org> Wed, 24 Mar 2021 10:12:53 +0100
+
swift (2.26.0-8) unstable; urgency=medium
* Kill the autopkgtests. The team has other means of testing swift anyways.
diff -Nru swift-2.26.0/debian/control swift-2.26.0/debian/control
--- swift-2.26.0/debian/control 2021-02-23 14:11:16.000000000 +0100
+++ swift-2.26.0/debian/control 2021-03-24 10:12:53.000000000 +0100
@@ -356,6 +356,7 @@
python3-barbicanclient,
python3-castellan,
python3-keystonemiddleware,
+ python3-dnspython,
Description: distributed virtual object store - proxy server
OpenStack Object Storage (code-named Swift) creates redundant, scalable object
storage using clusters of standardized servers to store petabytes of
diff -Nru swift-2.26.0/debian/patches/series swift-2.26.0/debian/patches/series
--- swift-2.26.0/debian/patches/series 2021-02-23 14:11:16.000000000 +0100
+++ swift-2.26.0/debian/patches/series 2021-03-24 10:12:53.000000000 +0100
@@ -4,3 +4,4 @@
set-default-workers-value.patch
fix-eventlet-monkey-patching-with-py3.7.patch
Fix__exit__calls.patch
+Turn_off_logging.logThreads_when_monkey-patched.patch
diff -Nru swift-2.26.0/debian/patches/Turn_off_logging.logThreads_when_monkey-patched.patch swift-2.26.0/debian/patches/Turn_off_logging.logThreads_when_monkey-patched.patch
--- swift-2.26.0/debian/patches/Turn_off_logging.logThreads_when_monkey-patched.patch 1970-01-01 01:00:00.000000000 +0100
+++ swift-2.26.0/debian/patches/Turn_off_logging.logThreads_when_monkey-patched.patch 2021-03-24 10:12:53.000000000 +0100
@@ -0,0 +1,31 @@
+Description: Turn off logging.logThreads when monkey-patched
+ We've seen proxy-servers lock up while trying to log client disconnects.
+ The trouble is that we happen to do this while we're *already*
+ trying to log *something else*. If the timing works out particularly
+ badly, we end up with a double-call to (an eventlet-patched)
+ threading.current_thread(), which needs to enumerate all pthreads, which
+ uses a non-re-entrant lock in CPython.
+ .
+ The most expedient solution seems to be disabling logThreads so we never
+ call threading.current_thread().
+Author: Tim Burke <tim.burke@gmail.com>
+Date: Thu, 17 Sep 2020 17:41:03 -0700
+Change-Id: Ida9418a1bd30ed300a8a850cda567d60c9889ec7
+Origin: https://review.opendev.org/c/openstack/swift/+/752593
+Last-Update: 2021-03-24
+
+diff --git a/swift/common/utils.py b/swift/common/utils.py
+index 83417ff..b31e9af 100644
+--- a/swift/common/utils.py
++++ b/swift/common/utils.py
+@@ -554,6 +554,10 @@
+ # if thread is monkey-patched.
+ eventlet.patcher.monkey_patch(all=False, socket=True, select=True,
+ thread=True)
++ # Trying to log threads while monkey-patched can lead to deadlocks; see
++ # https://bugs.launchpad.net/swift/+bug/1895739
++ logging.logThreads = 0
++
+ import __original_module_threading as orig_threading
+ import threading
+ orig_threading.current_thread.__globals__['_active'] = threading._active
Reply to: