#21520 closed defect (not a bug)

stem.process gets stuck

Reported by: Cornax Owned by: Cornax
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Blocker Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The code gets stuck on stem.process.launch_tor_with_config if we specify only one exit node and that exit is not running.

Child Tickets

Change History (11)

comment:1 Changed 19 months ago by atagar

Status: newneeds_information

Interesting. What log output does tor give?

def print_line(line):
  print(line)

stem.process.launch_tor_with_config(my_config, init_msg_handler = print_line)

comment:2 Changed 19 months ago by Cornax

Feb 21 23:47:27.022 [notice] Opening Socks listener on 127.0.0.1:9550
Feb 21 23:47:27.022 [notice] Opening Control listener on 127.0.0.1:9551
Feb 21 23:47:27.000 [notice] Bootstrapped 0%: Starting
Feb 21 23:47:27.000 [notice] Bootstrapped 45%: Asking for relay descriptors

comment:3 Changed 19 months ago by atagar

Component: Core Tor/StemCore Tor/Tor
Status: needs_informationnew

Ok. This isn't a stem issue (we simply invoke the tor command - you'd see that if running tor by hand too). Sending this over to Nick.

comment:4 Changed 19 months ago by Cornax

If i run tor by hand, this is the output:

Feb 22 00:08:35.018 [notice] Opening Socks listener on 127.0.0.1:9550
Feb 22 00:08:35.018 [notice] Opening Control listener on 127.0.0.1:9551
Feb 22 00:08:35.000 [notice] Bootstrapped 0%: Starting
Feb 22 00:08:36.000 [notice] Bootstrapped 45%: Asking for relay descriptors
Feb 22 00:08:38.000 [notice] Bootstrapped 50%: Loading relay descriptors
Feb 22 00:08:46.000 [notice] I learned some more directory information, but not
enough to build a circuit: We need more microdescriptors: we have 7134/7268, and

can only build 0% of likely paths. (We have 98% of guards bw, 98% of midpoint b

w, and 0% of exit bw = 0% of path bw.)

And some other nodes just run without error but when i try to make a request torrc keeps looping trying to find a new one.

Last edited 19 months ago by Cornax (previous) (diff)

comment:5 Changed 19 months ago by dgoulet

Resolution: not a bug
Status: newclosed

This is most likely an issue with your network (or local firewall policy). Seems you are able to download some descriptors but not all so this shows me that you are either heavily throttled or your connection is very unstable dropping packets.

You can always try to set FascistFirewall 1 in your torrc and see how it works out for you? Apart from that, I recommend you seek help on tor-talk@ mailing list or #tor IRC on OFTC about this problem of bootstrap. Provide as much details as you can including which tor version you are using and some debug logs if possible.

Closing this because there aren't any action items we can really work with and a Core Tor ticket for support is the best way for it to get forgotten :(.

comment:6 Changed 19 months ago by Cornax

This has nothing to do with my connection, the node i am trying to connect is not running i checked it on atlas. How come stem.process doesn't throw an error or stop with the default timeout?
Also i am not sure what this is about: "Note: The timeout argument does not work on Windows, and relies on the global state of the signal module."

comment:7 Changed 19 months ago by Cornax

Resolution: not a bug
Status: closedreopened

comment:8 Changed 19 months ago by atagar

Also i am not sure what this is about: "Note: The timeout argument does not work on Windows, and relies on the global state of the signal module."

https://gitweb.torproject.org/stem.git/commit/?id=688f3212

comment:9 in reply to:  6 Changed 19 months ago by dgoulet

Replying to Cornax:

This has nothing to do with my connection, the node i am trying to connect is not running i checked it on atlas. How come stem.process doesn't throw an error or stop with the default timeout?
Also i am not sure what this is about: "Note: The timeout argument does not work on Windows, and relies on the global state of the signal module."

This is not about Stem. Stem launches the tor daemon and then you get stuck downloading a descriptor that doesn't exists... It's actually proper behavior. Maybe what we want here is a new control event that says "Hey the ExitNode you asked for doesn't exists" and then Stem could pick up on that. But, this is then a feature request for both tor and stem :).

Last edited 19 months ago by dgoulet (previous) (diff)

comment:10 Changed 19 months ago by Cornax

I get it now, Thanks.

comment:11 Changed 19 months ago by Cornax

Resolution: not a bug
Status: reopenedclosed
Note: See TracTickets for help on using tickets.