[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #21974 [Core Tor/Tor]: Race: Tor declares controlport listener open before it has written its controlcookie to disk
#21974: Race: Tor declares controlport listener open before it has written its
controlcookie to disk
------------------------------+-----------------
Reporter: arma | Owner:
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Core Tor/Tor | Version:
Severity: Normal | Keywords:
Actual Points: | Parent ID:
Points: | Reviewer:
Sponsor: |
------------------------------+-----------------
When I start my Tor client, I see this in its logs:
{{{
Apr 17 00:49:35.238 [notice] Opening Control listener on 127.0.0.1:9051
}}}
In fact, controllers like txtorcon and nyx might imagine that they can use
this log line as an indication that the control port is up and usable:
https://github.com/meejah/txtorcon/blob/master/txtorcon/controller.py#L131
But looking through Tor's code, that log line comes from
connection_listener_new() which comes from retry_listener_ports() which
comes from retry_all_listeners() which comes from
options_act_reversible(), which gets called before options_act(), which is
where we call init_control_cookie_authentication().
So:
A) Is there a recommendation we can make to controllers about how they can
know when our control port is ready? I guess the answer right now is "when
the control port is open and also when the control cookie file is there"?
Is that accurate? Should we worry about races writing/reading the cookie
file?
B) Should we rearrange the order of stuff in options_act*() so things are
in place for the control port when we do the log message indicating that
it's open?
C) We sure have a bunch of stuff we do at startup now, and the dependency
of graph of what has to happen before what is complicated, and I bet there
are bugs in the current order of things. It would be a swell project for
somebody to make a list of all the things we do at startup, and figure out
their dependencies, and sort them into "waves" or something, and then
refactor the stuff in config.c so it matches the new world order. I'll
make a new ticket for that one.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21974>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs