Hello,
So I just updated the tor software using command “brew upgrade tor” on macOS. It upgraded from tor 0.3.3.0 to tor 0.3.3.6. I am wondering, do I need to restart my relay after doing this?
I am also wondering, I have this email address in the “ContactInfo” in my torn file for tor project to contact me regarding issues with my relay, etc, but am wondering if there is a way to have this email for them to contact without displaying it publicly on my relay?
Thank you very much.
Keifer Bly:
I am also wondering, I have this email address in the “ContactInfo” in my torn file for tor project to contact me regarding issues with my relay, etc, but am wondering if there is a way to have this email for them to contact without displaying it publicly on my relay?
The ContactInfo string is always public, but you can protect your current email from spamers by creating a second email address just for your ContactInfo field. (or by obfuscating it)
Thank you. Here is something I have noticed, my computer says it’s running tor 0.3.3.6 (upgraded today), but my status at https://metrics.torproject.org/rs.html#details/DB1AF6477BB276B6EA5E721326840... says it’s running a different version (0.3.2.10). Any idea on why this might be happening? Thanks very much.
Sent from my iPhone
On May 23, 2018, at 12:46 PM, nusenu nusenu-lists@riseup.net wrote:
Keifer Bly:
I am also wondering, I have this email address in the “ContactInfo” in my torn file for tor project to contact me regarding issues with my relay, etc, but am wondering if there is a way to have this email for them to contact without displaying it publicly on my relay?
The ContactInfo string is always public, but you can protect your current email from spamers by creating a second email address just for your ContactInfo field. (or by obfuscating it)
-- https://mastodon.social/@nusenu twitter: @nusenu_
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Here is something I have noticed, my computer says it’s running tor 0.3.3.6 (upgraded today), but my status at https://metrics.torproject.org/rs.html#details/DB1AF6477BB276B6EA5E721326840... says it’s running a different version (0.3.2.10). Any idea on why this might be happening?
As the uptime is more than 27 days, I would guess the Tor server software itself has not been restarted to actually use the updated version (0.3.3.6) and it still running on the old version (0.3.2.10) that was installed previously.
I have not worked on macOS services, but as I understand it, executing `sudo launchctl stop servicename && sudo launchctl stop servicename` should do the job for restarting the service, and `sudo launchctl list` should show the list of services so that you can find the service name itself. Maybe just restarting the box is an easier method of restarting the Tor service.
-- 4096R/A83CE748 Valters Jansons
On 24.05.18 08:17, Valter Jansons wrote:
I have not worked on macOS services, but as I understand it, executing `sudo launchctl stop servicename && sudo launchctl stop servicename` should do the job for restarting the service [...]
That might not work as intended, depending on macOS version and service configuration details. Both "stop" and "start" are legacy subcommands aimed at on-demand services and older launchd implementations.
Maybe just restarting the box is an easier method of restarting the Tor service.
Probably.
-Ralph
“killall tor” to stop the process then “tor” to start it again usually works, but I wonder if there is a way to do this without loosing uptime as this does? Thank you.
Sent from my iPhone
On May 24, 2018, at 4:30 AM, Ralph Seichter m16+tor@monksofcool.net wrote:
On 24.05.18 08:17, Valter Jansons wrote:
I have not worked on macOS services, but as I understand it, executing `sudo launchctl stop servicename && sudo launchctl stop servicename` should do the job for restarting the service [...]
That might not work as intended, depending on macOS version and service configuration details. Both "stop" and "start" are legacy subcommands aimed at on-demand services and older launchd implementations.
Maybe just restarting the box is an easier method of restarting the Tor service.
Probably.
-Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi Keifer,
When doing Tor version upgrades (and not just config changes), there is no way to restart the process without losing uptime; as uptime records the amount of time that the Tor process has been running without interruption.
When doing version upgrades, stopping your previous version of tor and starting the new version is required, this cannot be done without interrupting the uptime. That said, uptime is not a super important stat. It is more important that you keep your tor daemon / system up to date than go for high uptime numbers.
Thanks for running relays!
On May 24, 2018, at 1:01 PM, Keifer Bly keifer.bly@gmail.com wrote:
“killall tor” to stop the process then “tor” to start it again usually works, but I wonder if there is a way to do this without loosing uptime as this does? Thank you.
Sent from my iPhone
On May 24, 2018, at 4:30 AM, Ralph Seichter m16+tor@monksofcool.net wrote:
On 24.05.18 08:17, Valter Jansons wrote:
I have not worked on macOS services, but as I understand it, executing `sudo launchctl stop servicename && sudo launchctl stop servicename` should do the job for restarting the service [...]
That might not work as intended, depending on macOS version and service configuration details. Both "stop" and "start" are legacy subcommands aimed at on-demand services and older launchd implementations.
Maybe just restarting the box is an easier method of restarting the Tor service.
Probably.
-Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi, so I just restarted tor process, and this is the output
May 24 11:23:59.876 [notice] Tor 0.3.3.6 (git-7dd0813e783ae16e) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2o, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A. May 24 11:23:59.877 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning May 24 11:23:59.891 [notice] Read configuration file "/usr/local/etc/tor/torrc". May 24 11:23:59.894 [notice] Based on detected system memory, MaxMemInQueues is set to 3276 MB. You can override this by setting MaxMemInQueues by hand. May 24 11:23:59.895 [notice] Scheduler type KISTLite has been enabled. May 24 11:23:59.895 [notice] Opening OR listener on 0.0.0.0:9002 May 24 11:24:00.000 [notice] Parsing GEOIP IPv4 file /usr/local/Cellar/tor/0.3.3.6/share/tor/geoip. May 24 11:24:00.000 [notice] Parsing GEOIP IPv6 file /usr/local/Cellar/tor/0.3.3.6/share/tor/geoip6. May 24 11:24:00.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. May 24 11:24:01.000 [notice] Your Tor server's identity key fingerprint is 'torland DB1AF6477BB276B6EA5E72132684096EEE779D30' May 24 11:24:01.000 [notice] Bootstrapped 0%: Starting May 24 11:24:13.000 [notice] Starting with guard context "default" May 24 11:24:13.000 [notice] Bootstrapped 80%: Connecting to the Tor network May 24 11:24:13.000 [notice] Guessed our IP address as 71.80.215.102 (source: 204.13.164.118). May 24 11:24:14.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. May 24 11:24:14.000 [warn] tor_bug_occurred_: Bug: src/or/circuitbuild.c:2772: onion_extend_cpath: Non-fatal assertion info || client failed. (on Tor 0.3.3.6 7dd0813e783ae16e) May 24 11:24:14.000 [warn] Bug: Non-fatal assertion info || client failed in onion_extend_cpath at src/or/circuitbuild.c:2772. Stack trace: (on Tor 0.3.3.6 7dd0813e783ae16e) May 24 11:24:14.000 [warn] Bug: 0 tor 0x000000010b5c836b log_backtrace + 73 (on Tor 0.3.3.6 7dd0813e783ae16e) May 24 11:24:14.000 [warn] Bug: 1 tor 0x000000010b5dfe75 tor_bug_occurred_ + 266 (on Tor 0.3.3.6 7dd0813e783ae16e) May 24 11:24:14.000 [warn] Bug: 2 tor 0x000000010b4bda7a circuit_establish_circuit + 2340 (on Tor 0.3.3.6 7dd0813e783ae16e) May 24 11:24:14.000 [warn] Bug: 3 tor 0x000000010b4cf6b3 circuit_build_needed_circs + 436 (on Tor 0.3.3.6 7dd0813e783ae16e) May 24 11:24:14.000 [warn] Bug: 4 tor 0x000000010b55ce07 second_elapsed_callback + 803 (on Tor 0.3.3.6 7dd0813e783ae16e) May 24 11:24:14.000 [warn] Bug: 5 libevent-2.1.6.dylib 0x000000010b72e9c2 event_process_active_single_queue + 1057 (on Tor 0.3.3.6 7dd0813e783ae16e) May 24 11:24:14.000 [warn] Bug: 6 libevent-2.1.6.dylib 0x000000010b72bcb3 event_base_loop + 1074 (on Tor 0.3.3.6 7dd0813e783ae16e) May 24 11:24:14.000 [warn] Bug: 7 tor 0x000000010b55c865 do_main_loop + 1377 (on Tor 0.3.3.6 7dd0813e783ae16e) May 24 11:24:14.000 [warn] Bug: 8 tor 0x000000010b55ebf5 tor_run_main + 174 (on Tor 0.3.3.6 7dd0813e783ae16e) May 24 11:24:14.000 [warn] Bug: 9 tor 0x000000010b5c420d tor_main + 70 (on Tor 0.3.3.6 7dd0813e783ae16e) May 24 11:24:14.000 [warn] Bug: 10 tor 0x000000010b4aa253 main + 27 (on Tor 0.3.3.6 7dd0813e783ae16e) May 24 11:24:14.000 [warn] Bug: 11 libdyld.dylib 0x00007fff65c52015 start + 1 (on Tor 0.3.3.6 7dd0813e783ae16e) May 24 11:24:14.000 [warn] Bug: 12 ??? 0x0000000000000001 0x0 + 1 (on Tor 0.3.3.6 7dd0813e783ae16e) May 24 11:24:14.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit. May 24 11:24:14.000 [notice] Bootstrapped 85%: Finishing handshake with first hop May 24 11:24:16.000 [notice] Bootstrapped 90%: Establishing a Tor circuit May 24 11:24:17.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. May 24 11:24:17.000 [notice] Bootstrapped 100%: Done
Is the “tor_bug_occured” and “client failed” and all of that text something to be concerned about?
Thank you.
I have been keeping homebrew as well as the macOS operating system up to date as well as tor.
On May 24, 2018, at 11:22 AM, Colin Childs colin@torproject.org wrote:
Hi Keifer,
When doing Tor version upgrades (and not just config changes), there is no way to restart the process without losing uptime; as uptime records the amount of time that the Tor process has been running without interruption.
When doing version upgrades, stopping your previous version of tor and starting the new version is required, this cannot be done without interrupting the uptime. That said, uptime is not a super important stat. It is more important that you keep your tor daemon / system up to date than go for high uptime numbers.
Thanks for running relays!
On May 24, 2018, at 1:01 PM, Keifer Bly keifer.bly@gmail.com wrote:
“killall tor” to stop the process then “tor” to start it again usually works, but I wonder if there is a way to do this without loosing uptime as this does? Thank you.
Sent from my iPhone
On May 24, 2018, at 4:30 AM, Ralph Seichter m16+tor@monksofcool.net wrote:
On 24.05.18 08:17, Valter Jansons wrote:
I have not worked on macOS services, but as I understand it, executing `sudo launchctl stop servicename && sudo launchctl stop servicename` should do the job for restarting the service [...]
That might not work as intended, depending on macOS version and service configuration details. Both "stop" and "start" are legacy subcommands aimed at on-demand services and older launchd implementations.
Maybe just restarting the box is an easier method of restarting the Tor service.
Probably.
-Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi,
On 24 May 2018, at 11:27, Keifer Bly keifer.bly@gmail.com wrote:
May 24 11:24:14.000 [warn] Bug: Non-fatal assertion info || client failed in onion_extend_cpath at src/or/circuitbuild.c:2772. Stack trace: (on Tor 0.3.3.6 7dd0813e783ae16e)
Thanks for reporting this bug!
It's a known issue, and we are testing a fix in our master branch and alpha releases: https://trac.torproject.org/projects/tor/ticket/25692
I have asked if we can backport the fix to the next 0.3.3 release: https://trac.torproject.org/projects/tor/ticket/25691#comment:25
T
What does it mean? Does it mean my relay will be unreachable? Thank you.
Sent from my iPhone
On May 24, 2018, at 11:40 AM, teor teor2345@gmail.com wrote:
Hi,
On 24 May 2018, at 11:27, Keifer Bly keifer.bly@gmail.com wrote:
May 24 11:24:14.000 [warn] Bug: Non-fatal assertion info || client failed in onion_extend_cpath at src/or/circuitbuild.c:2772. Stack trace: (on Tor 0.3.3.6 7dd0813e783ae16e)
Thanks for reporting this bug!
It's a known issue, and we are testing a fix in our master branch and alpha releases: https://trac.torproject.org/projects/tor/ticket/25692
I have asked if we can backport the fix to the next 0.3.3 release: https://trac.torproject.org/projects/tor/ticket/25691#comment:25
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 24 May 2018, at 11:48, Keifer Bly keifer.bly@gmail.com wrote:
What does it mean? Does it mean my relay will be unreachable? Thank you.
This bug happens because Tor doesn't check for relay information correctly.
It's harmless on relays, and you should ignore it.
T
EDIT: It also just popped up with "May 24 11:25:18.000 [notice] Performing bandwidth self-test…done.”
Thank you.
On May 24, 2018, at 11:22 AM, Colin Childs colin@torproject.org wrote:
Hi Keifer,
When doing Tor version upgrades (and not just config changes), there is no way to restart the process without losing uptime; as uptime records the amount of time that the Tor process has been running without interruption.
When doing version upgrades, stopping your previous version of tor and starting the new version is required, this cannot be done without interrupting the uptime. That said, uptime is not a super important stat. It is more important that you keep your tor daemon / system up to date than go for high uptime numbers.
Thanks for running relays!
On May 24, 2018, at 1:01 PM, Keifer Bly keifer.bly@gmail.com wrote:
“killall tor” to stop the process then “tor” to start it again usually works, but I wonder if there is a way to do this without loosing uptime as this does? Thank you.
Sent from my iPhone
On May 24, 2018, at 4:30 AM, Ralph Seichter m16+tor@monksofcool.net wrote:
On 24.05.18 08:17, Valter Jansons wrote:
I have not worked on macOS services, but as I understand it, executing `sudo launchctl stop servicename && sudo launchctl stop servicename` should do the job for restarting the service [...]
That might not work as intended, depending on macOS version and service configuration details. Both "stop" and "start" are legacy subcommands aimed at on-demand services and older launchd implementations.
Maybe just restarting the box is an easier method of restarting the Tor service.
Probably.
-Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
Colin Childs -
Keifer Bly -
nusenu -
Ralph Seichter -
teor -
Valter Jansons