Opened 13 years ago

Last modified 8 years ago

#384 closed defect (Fixed)

don't retry immediately if a dirserver returns 403

Reported by: arma Owned by: nickm
Priority: Low Milestone: post 0.1.2.x
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


moria1 and moria2 are going nuts requesting stuff from lefkada, which is
misconfigured to return "403 forbidden" on each request. They're making a
request every couple of seconds, and they're not letting up.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (7)

comment:1 Changed 13 years ago by nickm

Hmmm. I could use some context here. We track failure differently for every resource, so
it matters what moria1 and moria2 are freaking out about.

Also, logs would help: were we marking lefkada down and marking it as up again, or were we
ignoring "down"ness?

comment:2 Changed 13 years ago by arma

We should reconstruct this situation so we get suitable logs, and then fix it.

But since it doesn't happen that often, it's fine to push this to 0.2.0.x.

comment:3 Changed 13 years ago by arma

Dizum is down, and this bug is now emerged again.

moria5 has its dirport open, and it is attempting to fetch 1290 descriptors
from dizum every 10 seconds. It never stops trying. I'm guessing only dizum
lists these descriptors, and they're old, but moria5 wants to cache them anyway. has all the detail you might want.

As for the call in connection_dir_request_failed(), dizum is already marked
as is_running=0, and nothing is setting it to running again, so it's not a
matter of flapping.

I think the problem is in update_router_descriptor_cache_downloads(), where
we add the descriptor to downloadable whether or not the networkstatus is
listed as running. The
SMARTLIST_FOREACH(networkstatus_list) loop has a comment saying "and we haven't
already failed to get that descriptor from the corresponding authority" but
I don't see where in that function it enforces that. (Is that a separate bug?)

Maybe a clause right above the SMARTLIST_FOREACH(ns->entries) loop that says
"if this networkstatus is down, continue" would help here?

comment:4 Changed 13 years ago by arma

r9880 resolved the problem for me. I'm not sure if it's the correct solution
long-term though.

comment:5 Changed 13 years ago by arma

Calling this one fixed in r9880 / r10175.

comment:6 Changed 13 years ago by arma

flyspray2trac: bug closed.

comment:7 Changed 8 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.