Parsing a networkstatus-bridges with flags only causes BridgeDB to hang
View options
The following file:
bridgedb@polyanthum /srv/bridges.torproject.org/from-bifroest
% cat networkstatus-bridges
published 2017-08-15 18:58:10
flag-thresholds stable-uptime=0 stable-mtbf=0 fast-speed=0 guard-wfu=0.000% guard-tk=0 guard-bw-inc-exits=0 guard-bw-exc-exits=0 enough-mtbf=1 ignoring-advertised-bws=0 causes the bridgedb process to hang. The last log lines output are:
bridgedb@polyanthum ~ % tail -f /srv/bridges.torproject.org/log/bridgedb.log
19:46:33 INFO L465:Bridges.insert() BridgeSplitter placing bridge $$C44836BF2F42DB5B1AD3CF6085626056593D846A~Shizuokalibelous into hashring https (via n=5, pos=0).
19:46:33 DEBUG L547:Bridges.insert() Inserting $$C44836BF2F42DB5B1AD3CF6085626056593D846A~Shizuokalibelous into hashring...
19:46:33 DEBUG L78:geo.getCountryCode() Looked up country code: NL
19:46:33 INFO L465:Bridges.insert() BridgeSplitter placing bridge $$2CC6A05D7F52D7B936ABEE13C782780E4B23B64F~conglutinatoreri into hashring email (via n=14, pos=1).
19:46:33 DEBUG L547:Bridges.insert() Inserting $$2CC6A05D7F52D7B936ABEE13C782780E4B23B64F~conglutinatoreri into hashring...
19:46:33 INFO L174:Main.load() Done inserting 1959 bridges into hashring.
19:46:33 DEBUG L208:persistent.save() Saving state to: '/srv/bridges.torproject.org/run/bridgedb.state'
19:46:33 INFO L80:Main.load() Processing descriptors in ../from-bifroest directory...
19:46:33 INFO L86:Main.load() Opening networkstatus file: /srv/bridges.torproject.org/from-bifroest/networkstatus-bridges
19:46:33 INFO L124:descriptors.parseNetwo() Parsing networkstatus file: /srv/bridges.torproject.org/from-bifroest/networkstatus-bridgesFurther, and this might be a separate issue, but when BridgeDB hangs in this state, the cronjob which calls bridgedb --reload launches an entirely new process of bridgedb, without killing the old one, since the old one is locked while doing blocking IO, and the signal handlers are in the async code that it's supposed to come back to. I think there's not really any way to fix this, since Stem is doing the IO there, and Stem isn't async aware/capable.