Skip to content
Snippets Groups Projects

stem.process gets stuck

    • Closed (moved) Issue created by Trac @tracbot

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

    Trac:
    Username: Cornax

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Trac added component::core tor/tor owner::Cornax priority::medium reporter::Cornax resolution::not a bug severity::blocker status::closed type::defect labels

      added component::core tor/tor owner::Cornax priority::medium reporter::Cornax resolution::not a bug severity::blocker status::closed type::defect labels

    • A
      Damian Johnson @atagar ·

      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)

      Trac:
      Status: new to needs_information

    • Trac
      Trac @tracbot ·
      Author

      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

      Trac:
      Username: Cornax

    • A
      Damian Johnson @atagar ·

      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.

      Trac:
      Status: needs_information to new
      Component: Core Tor/Stem to Core Tor/Tor

    • Trac
      Trac @tracbot ·
      Author

      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.

      Trac:
      Username: Cornax

    • David Goulet
      David Goulet @dgoulet ·

      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 :(.

      Trac:
      Resolution: N/A to not a bug
      Status: new to closed

    • Trac
      Trac @tracbot ·
      Author

      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."

      Trac:
      Username: Cornax

    • Trac
      Trac @tracbot ·
      Author

      Trac:
      Username: Cornax
      Resolution: not a bug to N/A
      Status: closed to reopened

    • A
      Damian Johnson @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

    • David Goulet
      David Goulet @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 :).

    • Trac
      Trac @tracbot ·
      Author

      I get it now, Thanks.

      Trac:
      Username: Cornax

    • Trac
      Trac @tracbot ·
      Author

      Trac:
      Username: Cornax
      Status: reopened to closed
      Resolution: N/A to not a bug

    • Trac closed

      closed

    • David Goulet mentioned in issue #21529 (moved)

      mentioned in issue #21529 (moved)

    • Trac moved to tpo/core/tor#21520 (closed)

      moved to tpo/core/tor#21520 (closed)

    • Trac mentioned in issue tpo/core/tor#21529 (closed)

      mentioned in issue tpo/core/tor#21529 (closed)

    Please register or sign in to reply