[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [tor/maint-0.2.2] Don't recreate descriptor on sighup
commit 3ff7925a7027b81cb9f14b0863972b4d4e5b46a4
Author: Sebastian Hahn <sebastian@xxxxxxxxxxxxxx>
Date: Sat May 21 19:10:11 2011 +0200
Don't recreate descriptor on sighup
We used to regenerate our descriptor whenever we'd get a sighup. This
was caused by a bug in options_transition_affects_workers() that would
return true even if the options were exactly the same. Down the call
path we'd call init_keys(), which made us make a new descriptor which
the authorities would reject, and the node would subsequently fall out
of the consensus.
This patch fixes only the first part of this bug:
options_transition_affects_workers() behaves correctly now. The second
part still wants a fix.
---
changes/bug1810 | 6 ++++++
src/or/config.c | 2 +-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/changes/bug1810 b/changes/bug1810
new file mode 100644
index 0000000..11e561f
--- /dev/null
+++ b/changes/bug1810
@@ -0,0 +1,6 @@
+ o Major bugfixes:
+ - Don't decide to make a new descriptor when receiving a HUP signal.
+ This bug has caused a lot of relays to disappear from the consensus
+ periodically. Fixes the most common case of triggering bug 1810;
+ bugfix on 0.2.2.7-alpha.
+
diff --git a/src/or/config.c b/src/or/config.c
index 68a6b29..36fb991 100644
--- a/src/or/config.c
+++ b/src/or/config.c
@@ -3809,7 +3809,7 @@ options_transition_affects_workers(or_options_t *old_options,
old_options->ORPort != new_options->ORPort ||
old_options->ServerDNSSearchDomains !=
new_options->ServerDNSSearchDomains ||
- old_options->SafeLogging != new_options->SafeLogging ||
+ old_options->_SafeLogging != new_options->_SafeLogging ||
old_options->ClientOnly != new_options->ClientOnly ||
public_server_mode(old_options) != public_server_mode(new_options) ||
!config_lines_eq(old_options->Logs, new_options->Logs) ||
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits