Rephrase "missing descriptors" notice log to be less confusing
Some operators are confused or alarmed by these logs:
Sep 05 03:22:50.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 6515/6541).
Sep 05 03:22:50.000 [notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 6515/6541).We should rephrase them or document that:
- tor tries to keep active 3 primary guards for anonymity and safety
- we'll try to get new microdescs soon
- tor usually recovers quickly from this issue
Activity
changed milestone to %Tor: 0.4.1.x-final
Trac:
Parent Ticket: #21969 (moved)
Child Ticket(s): #31644 (moved)added 035-backport? 040-backport? 041-backport? 042-should BugSmashFund actualpoints::0.1 component::core tor/tor consider-backport-after-0421 fast-fix log milestone::Tor: 0.4.1.x-final owner::teor parent::21969 points::0.1 priority::medium resolution::implemented reviewer::ahf severity::normal status::closed tor-bridge tor-client tor-guard type::defect version::tor 0.3.3.1-alpha labels
See my pull request:
I added a short explanation to the existing log message, and updated the test that depends on that message.
The merge forward was clean. Here are the test branches for merging forwards:
Trac:
Version: Tor: 0.3.0.6 to Tor: 0.3.3.1-alpha
Status: assigned to needs_review
Keywords: doc? deleted, BugSmash added
Actualpoints: N/A to 0.1
I'm OK with the change, but if the log message should not be acted upon, why should we expose it to the users as a [notice]?
Is it so that if we ever get issues like (#30746 (moved)/#21969 (moved)) again we know that this is the underlying issue? In this case, could we just output this message just in pathological cases?
I'm marking this as needs_revision to hear teor's opinion.
Trac:
Status: needs_review to needs_revision-
Replying to teor:
How do we reliably detect pathological cases? Suppress the message, until it occurs a few times within a short timeframe?
That's a good question I don't have an answer for.
Unfortunately, I don't think that's the kind of message that occurs multiple times, looking at #30746 (moved) (and friends) this seems to be able to cause havoc with just a single repeatition.
I'm not sure why this is the case, since
router_have_minimum_dir_info()seems to be called all the time and that should eventually callentry_guards_get_err_str_if_dir_info_missing()which is the source of the log message... Things are kinda messy between these two functions tho, so it's kinda hard to understand what's the issue.Perhaps we can merge this patch for now since it does not seem to make the situation worse, and we can think in the future how to improve the UX? If you agree, feel free to toggle this into merge_ready since the patch LGTM.
Let's deal with the UX / behaviour in #31707 (moved).
mentioned in issue #31707 (moved)
mentioned in issue #31644 (moved)
moved to tpo/core/tor#31657 (closed)
mentioned in issue tpo/core/tor#31707 (closed)
