zombie processes after shutdown signal.

[23cku0r]

How to properly shutdown the tor process? I always have zombie processes

I use this to shutdown tor.

And get zombie processes

I use this to run tor and i dont have access to proc after

[atagar]

Hi 23cku0r. To figure out what's up you'll need Tor's log. You can do so as follows. Replacing DEBUG with NOTICE to start with will likely be more helpful...

proc = stem.process.launch_tor_with_config(
  config = {
    'SocksPort': str(port),
    'ControlPort': str(get_control_port(port)),
    'Log': 'DEBUG file /tmp/tor_debug_log',
  }
)

[23cku0r]

• Mar 31 01:21:50.000 [notice] Tor 0.4.7.10 opening new log file.
• Mar 31 01:21:50.737 [notice] We compiled with OpenSSL 30000050: OpenSSL 3.0.5 5 Jul 2022 and we are running with OpenSSL 30000050: 3.0.5. These two versions should be binary compatible.
• Mar 31 01:21:50.739 [notice] Tor 0.4.7.10 running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.5, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.5.2 and Glibc 2.36 as libc.
• Mar 31 01:21:50.739 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/
• Mar 31 01:21:50.740 [warn] ControlPort is open, but no authentication method has been configured. This means that any program on your computer can reconfigure your Tor. That's bad! You should upgrade your Tor controller as soon as possible.
• Mar 31 01:21:50.740 [notice] I think we have 128 CPUS, but only 2 of them are available. Telling Tor to only use 2. You can override this with the NumCPUs option
• Mar 31 01:21:50.740 [notice] Opening Socks listener on 127.0.0.1:9577
• Mar 31 01:21:50.740 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9577
• Mar 31 01:21:50.740 [notice] Opening Control listener on 127.0.0.1:9422
• Mar 31 01:21:50.740 [notice] Opened Control listener connection (ready) on 127.0.0.1:9422
• Mar 31 01:21:50.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
• Mar 31 01:21:50.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
• Mar 31 01:21:50.000 [notice] Bootstrapped 0% (starting): Starting
• Mar 31 01:21:51.000 [notice] Starting with guard context "default"
• Mar 31 01:21:52.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
• Mar 31 01:21:53.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
• Mar 31 01:21:53.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
• Mar 31 01:21:53.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
• Mar 31 01:21:53.000 [notice] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
• Mar 31 01:21:53.000 [notice] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
• Mar 31 01:21:53.000 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus
• Mar 31 01:21:54.000 [notice] Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors
• Mar 31 01:21:54.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 25/6513, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of exit bw = 0% of path bw.)
• Mar 31 01:21:54.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 25/6513, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of exit bw = 0% of path bw.)
• Mar 31 01:21:54.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 25/6513, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of exit bw = 0% of path bw.)
• Mar 31 01:21:54.000 [notice] Bootstrapped 50% (loading_descriptors): Loading relay descriptors
• Mar 31 01:21:55.000 [notice] Bootstrapped 56% (loading_descriptors): Loading relay descriptors
• Mar 31 01:21:55.000 [notice] Bootstrapped 63% (loading_descriptors): Loading relay descriptors
• Mar 31 01:21:55.000 [notice] Bootstrapped 68% (loading_descriptors): Loading relay descriptors
• Mar 31 01:21:55.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
• Mar 31 01:21:55.000 [notice] Bootstrapped 80% (ap_conn): Connecting to a relay to build circuits
• Mar 31 01:21:56.000 [notice] Bootstrapped 85% (ap_conn_done): Connected to a relay to build circuits
• Mar 31 01:21:56.000 [notice] Bootstrapped 89% (ap_handshake): Finishing handshake with a relay to build circuits
• Mar 31 01:21:56.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
• Mar 31 01:21:56.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
• Mar 31 01:21:57.000 [notice] Bootstrapped 100% (done): Done
• Mar 31 01:22:20.000 [notice] New control connection opened from 127.0.0.1.
• Mar 31 01:22:20.000 [notice] Interrupt: exiting cleanly.

[atagar]

Odd. Stem can't improve this (it simply issues the shutdown signal to the tor process). I'd suggest reaching out to the upstream project: https://support.torproject.org/misc/bug-or-feedback/

Sorry I can't be more help.

[23cku0r]

Replacing line 128 in process.py to tor_process = subprocess.Popen(' '.join(runtime_args), stdout = subprocess.PIPE, stdin = subprocess.PIPE, stderr = subprocess.PIPE, shell=True) fixes this problem