GitLab

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.