- Mar 05, 2019
-
-
juga authored
-
juga authored
-
juga authored
When SocketClosed is raised and the scanner is stopping, catch the exception. In #28869 similar exceptions were catched, but this was forgotten. Bugfix v0.6.0.
-
juga authored
-
juga authored
-
juga authored
-
juga authored
Leave CHANGELOG.md until there's an actual new release, in case the unreleased changes are lost. Once CHANGELOG.md is removed, update the symlinks.
- Mar 03, 2019
-
-
juga authored
-
- Feb 28, 2019
-
-
juga authored
-
juga authored
-
juga authored
since testnets dir has been removed.
-
juga authored
-
juga authored
used to run the scanner. The test that runs the scanner was introduced by #28788.
-
juga authored
Closes: #29299.
-
juga authored
so that they can be reported in the bandwidth file headers.
-
juga authored
-
juga authored
To be able to add them to the bandwidth file so that we can diversify the locations and/or know how the location affects the bandwidth results.
-
- Feb 27, 2019
-
-
juga authored
that can happen from requests, so that they can later be stored in a Result.
-
juga authored
Since the exception happens in a thread, not the main process, use print_traceback to print the traceback.
-
juga authored
when dumping stack.
-
juga authored
before stopping the scanner.
-
juga authored
We changed conf['paths']['X'] to use conf.getpath('paths', 'X'), so that paths with `~` get expanded, but cleanup was forgotten. Also remove extra path check in main. And run cleanup as part of the integration tests. Bugfix v0.7.0.
-
- Feb 26, 2019
-
-
juga authored
Change tests added in #28897 with the changes introduced in #28736.
-
juga authored
Exit the scanner with error stoping threads first when there is not any functional destination, since the destinations can not be recovered. After merging #28897, `stop_threads` can be used (instroduced in #28869).
-
juga authored
-
juga authored
Add methods to store consecutive destination failures and retrieve the destinations that are still functional. Since destinations can fail because of Tor circuits, it's not count individual failures but consecutives one. Also exit with error if there are no functional destinations left. The maximum number of consecuitve failures is set to 10, but it may need to be changed depending on the percentage of circuits and requests that fail.
-
juga authored
in every measurement. This removes the need for an extra lock for every measurement It should also not be depending on a time interval, but on the number of failures detected. Not counting number of failures since it would need to modify the destination or list of at runtime. It should be done in a future refactor. Fixes bug #28897. Bugfix v0.3.0
-
- Feb 25, 2019
-
-
juga authored
-
juga authored
and create function to set options that can fail because they are not supported by some Tor versions at runtime. Fixes bug 28692. Bugfix v0.4.0
-
juga authored
The log message might not correspond to the reason. Only the first one that fails will be logged, but not refactoring here. Add an integration test to check a runtime option fails.
-
juga authored
to a function. Replace comment by docstring. Add an integration test to check the option is set.
-
- Feb 24, 2019
-
-
juga authored
-
- Feb 23, 2019
-
-
juga authored
-
juga authored
after finishing the first loop. As noted in bug28933_01.
-
juga authored
Solved conflicts: sbws/core/scanner.py tox.ini
-
juga authored
Solved conflicts: docs/source/specification.rst
-
juga authored
-
juga authored
The bandwidth file is generated only with relays that have some successful measurements, but we forgot to load all results (including the relays with failed measurements) after we started to include the number of failure measurements in each relay bandwidth line. Closes #29568. Bugfix v0.4.0 (line introduced in v0.1.0).
-
- Feb 22, 2019
-
-
juga authored
-