Parsing a networkstatus-bridges with flags only causes BridgeDB to hang
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-bridges
Further, 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.