[tor-bugs] #32059 [Core Tor/Tor]: Bug when reading accounting interval while starting a new relay
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Oct 15 05:56:27 UTC 2019
#32059: Bug when reading accounting interval while starting a new relay
--------------------------+------------------------------------
Reporter: willbarr | Owner: (none)
Type: defect | Status: new
Priority: Low | Milestone: Tor: 0.4.3.x-final
Component: Core Tor/Tor | Version: Tor: 0.3.5.8
Severity: Normal | Resolution:
Keywords: backport? | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------+------------------------------------
Comment (by arma):
Thanks. Yes, this is definitely a bug.
I recommend against a backport, since the user-facing issue is "just" a
confusing log message that says "Bug".
The underlying problem is that our start-up / initialization code is all
tied around itself. We're loading the torrc file, so we load the state
file, but we don't have one yet so we write a new state file, but to save
the state file we need to check on our current accounting status, so we
initialize that, but somewhere along the way we decided that
accounting_set_wakeup_time() should be deterministic, and we base it on
your relay identity key, but on first start we don't have one yet, so we
generate one, and after we've made it we want to make sure it parses, so
we make a router descriptor for ourselves, but to properly make a router
descriptor we need to know if we're going to list our DirPort in the
descriptor, and to decide that we need to figure out if we're likely to
exceed our accountingmax value in the current accounting interval, because
if we are then we'll opt not to list the dirport. And remember, this is
all happening because we loaded Tor's state file and found that it wasn't
there yet. Then way way way later in options_act, we call things like
{{{
/* Set up accounting */
if (accounting_parse_options(options, 0)<0) {
...
}
if (accounting_is_enabled(options))
configure_accounting(time(NULL));
}}}
You can see why I recommend against a backport. :)
We could fix this particular issue by making that log_warn(LD_BUG) in
router_should_be_dirserver() be quieter. I guess that is orthogonal to
whether we should try to untangle the startup initialization stuff --
which is really related to the upcoming modularization work.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32059#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list