Re: Server node stalls on unsuccessful socks listener change

[coderman <coderman@xxxxxxxxx>]

On 8/21/07, coderman <coderman@xxxxxxxxx> wrote:
> ...
> this appears to be a linux'ism and applies only when going from an
> unspecified bind (0.0.0.0) to a specified bind to an address on the
> host.  changing specified bind addresses works as expected.

two issues here, one that i completely overlooked (thanks tup!)

the linux'ism described above may or may not be a problem.  there is a
bigger issue affecting all platforms first:

when reloading the config (ala SIGHUP or control port), the Tor
process tries to apply the various settings in an "undoable" fashion,
such that if the configuration fails, it reverts to its previous
state.  that is, set_options tries options_act_reversible which calls
retry_all_listeners which calls retry_listeners for each type with a
replaced_conns passed.

this results in behavior where a listening socket bound to 0.0.0.0 is
open at the same time tor tries to bind to a specified address, like
127.0.0.1, which obviously fails.  this doesn't cause a problem when
you start with a specified address because multiple specified
addresses can be bound to the same port since Tor is using
SO_REUSEADDR.

question for the Tor devs:

two possible ways to resolve this:
1. check for a change from unspecified to specified address in any of
the settings and disallow it.  (this should generate a warning in the
options_transition_allowed() checks)

2. modify retry_listeners so that when a listen port is previously
bound to 0.0.0.0 it does the following:
a. close the existing port immediately, instead of adding it to the
replace queue.
b. add this 0.0.0.0:port to an "undo" list in case subsequent changes fail.
c. bind to the new address:port and return success, or
d. close the attempted socket which caused a failed bind, and re-open
the previous 0.0.0.0:port socket so undo behavior is preserved.

i'd really like to be able to modify a running instance to change from
unspecified to specified binds without a restart.  this bit me once
already, and i think it is worth pursuing unless too complicated to
implement.

last caveat: the linux'ism still may be a problem.  the apparent
workaround for this is a small delay before rebinding.  the fix above
would at least correct the behavior on most platforms, leaving loonix
to be dealt with if needed.

best regards,