published new server descriptor but authorities dropped because cosmetic

yesterday my exit node was running but not relaying. no data in and out but huge jump in incoming connections. i restarted Tor as suggested in irc chat and that normalize everything but today repeated the problem but with a difference. yesterday - connections established but not relaying today - connections established and relaying. but both occurrences drop from the consensus.

lot49

Trac:
Username: Trystero

changed milestone to %Tor: 0.2.2.x-final in legacy/trac

added component::core tor/tor in Legacy / Trac milestone::Tor: 0.2.2.x-final in Legacy / Trac priority::very high in Legacy / Trac reporter::Trystero in Legacy / Trac resolution::fixed in Legacy / Trac status::closed in Legacy / Trac tor-relay in Legacy / Trac type::defect in Legacy / Trac labels

It's not mentioned in any of the votes either.

Here's our hint, from moria1's logs:

Aug 07 00:44:40.914 [info] dirserv_orconn_tls_done(): Found router lot49 to be reachable. Yay. Aug 07 01:06:00.721 [info] dirserv_orconn_tls_done(): Found router lot49 to be reachable. Yay. Aug 07 01:18:40.696 [info] dirserv_add_descriptor(): Not replacing descriptor from 'lot49' (source: 69.163.34.69); differences are cosmetic. Aug 07 01:27:21.478 [info] dirserv_orconn_tls_done(): Found router lot49 to be reachable. Yay. Aug 07 01:48:51.213 [info] dirserv_orconn_tls_done(): Found router lot49 to be reachable. Yay. Aug 07 02:09:30.515 [info] dirserv_add_descriptor(): Not replacing descriptor from 'lot49' (source: 69.163.34.69); differences are cosmetic. Aug 07 02:10:11.153 [info] dirserv_orconn_tls_done(): Found router lot49 to be reachable. Yay. Aug 07 02:31:30.813 [info] dirserv_orconn_tls_done(): Found router lot49 to be reachable. Yay. Aug 07 02:52:51.334 [info] dirserv_orconn_tls_done(): Found router lot49 to be reachable. Yay.

So what happened during these two publishes to make lot49 republish but to make moria1 think it didn't have anything new to say?

See also whichever bug it is where the Tor relay ought to recognize that its publish didn't take, and reschedule the new descriptor for the more suitable time.

Somewhere in the 0.2.3.x timeline we want to revamp the publish-retry logic a little bit anyway; let's try to make stuff more robust here then.

Trac:
Milestone: N/A to Tor: 0.2.3.1-alpha
Priority: major to normal

(The relay-side retry logic might turn out to be a backport candidate.)

Trac:
Milestone: Tor: 0.2.3.1-alpha to Tor: 0.2.3.x-final

Trac:
Summary: drop from consensus to published new server descriptor but authorities dropped because cosmetic

The authority side of the fix is imo legacy/trac#2479 (moved).

Leaving this trac entry in place though since we want to know why relays are publishing new descriptors that aren't different enough from the old ones.

Trac:
Points: N/A to N/A
Actualpoints: N/A to N/A

rransom noticed the republication is caused by a sighup, which debian does daily. So, bad luck for the poor operator who runs on Debian.

The issue is that we end up calling set_onion_key() on each sighup, which calls mark_my_descriptor_dirty() unconditionally. This has another fun implication if I'm reading it right: we never actually rotate our onion key.

Trac:
Priority: normal to major

Trac:
Milestone: Tor: 0.2.3.x-final to Tor: 0.2.2.x-final
Priority: major to critical

What's the call path from do_hup() to set_onion_key()?

do_hup() --> options_init_from_torrc() --> options_init_from_string() --> set_options() --> options_act() --> init_keys() --> set_onion_key()

what makes options_transition_affects_workers() return true?

So, the first part of the bug is fixed in bug1810 in my repository. The onion key rotation path is not, which causes more subtleties.

Trac:
Status: new to needs_review

Replying to Sebastian:

The issue is that we end up calling set_onion_key() on each sighup, which calls mark_my_descriptor_dirty() unconditionally. This has another fun implication if I'm reading it right: we never actually rotate our onion key.

set_onion_key is only called from one line in init_keys, and init_keys clobbers onionkey_set_at immediately after that call, so I don't think the extra calls to set_onion_key prevent onion key rotation.

Merged. Thanks! (I modified your changes file a bit, to take out the part about onion key rotation)

I think maybe we should close this ticket, and if the symptoms reoccur we can either reopen it or open a new one?

The ‘other part’ mentioned in the commit message may be that init_keys still marks the descriptor as dirty unconditionally.

Replying to rransom:

The ‘other part’ mentioned in the commit message may be that init_keys still marks the descriptor as dirty unconditionally.

I just opened legacy/trac#3263 (moved) for that one. Thanks.

Right, that was the other part. If this happens again we should open a new ticket.

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Trac:
Keywords: N/A deleted, tor-relay added

Trac:
Component: Tor Relay to Tor

closed

mentioned in issue legacy/trac#3252 (moved)

mentioned in issue legacy/trac#3263 (moved)

mentioned in issue legacy/trac#3265 (moved)

mentioned in issue legacy/trac#3277 (moved)

mentioned in issue legacy/trac#3327 (moved)

moved from legacy/trac#1810 (moved)

added Bug label and removed 1 deleted label

added Relay label and removed 1 deleted label