Hi Damian! On Wed, Dec 14, 2011 at 09:58:41AM -0800, Damian Johnson wrote:
Hi Stephan. This is the first that I've heard of connection panel issues related to upgrading. Here's some things to check...
Well, I checked my aptitude log, and tor-arm was the only upgraded tor packaged. My tor version is 0.2.2.34 (recommended) (from the arm tool, Debian version 0.2.2.34-1~~squeeze+1).
The older version of arm was running as root, the new version is running as debian-tor user (I tried it as root user with the same symptoms).
- When connection resolution fails several times arm falls back to another connection resolver, logging a notice as it does so. Do you have any connection related log messages?
Here are the log messages when I start arm as root (from today): 09:02:43 [ARM_NOTICE] Unable to prepopulate bandwidth information (insufficient uptime) 09:02:43 [ARM_NOTICE] Arm is currently running with root permissions. This is not a good idea, and will still work perfectly well if it's run with the same user as Tor (ie, starting with "sudo -u debian-tor arm"). 09:02:43 [ARM_NOTICE] No armrc loaded, using defaults. You can customize arm by placing a configuration file at '/root/.arm/armrc' (see the armrc.sa- mple for its options). 09:02:43 [NOTICE] New control connection opened. 02:40:12 [NOTICE] Tor 0.2.2.34 (git-c55c166e73d500af) opening new log file.Here are the logs from yesterday, running arm as debian-tor user and having tor restarted:
12:14:35 [NOTICE] Performing bandwidth self-test...done. â â12:13:22 [NOTICE] Self-testing indicates your DirPort is reachable from the outside. Excellent. â â12:12:37 [ARM_NOTICE] Unable to prepopulate bandwidth information (insufficient uptime) â â12:12:37 [ARM_NOTICE] No armrc loaded, using defaults. You can customize arm by placing a configuration file at '/var/lib/tor/.arm/armrc' (see the â â armrc.sample for its options). â â12:12:37 [NOTICE] New control connection opened. â â12:12:22 [NOTICE] Bootstrapped 100%: Done. â â12:12:22 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working. â â12:12:19 [NOTICE] Bootstrapped 90%: Establishing a Tor circuit. â â12:12:18 [NOTICE] Bootstrapped 85%: Finishing handshake with first hop. â â12:12:18 [NOTICE] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. â â12:12:18 [NOTICE] Bootstrapped 80%: Connecting to the Tor network. â â12:12:18 [NOTICE] We now have enough directory information to build circuits. â â12:12:15 [NOTICE] Your Tor server's identity key fingerprint is 'fsingtor D21CA85C6658E17E366E6D1309F6D0EA0A665134' â â12:12:15 [NOTICE] OpenSSL OpenSSL 0.9.8o 01 Jun 2010 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation â â12:12:15 [NOTICE] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.â â12:12:14 [NOTICE] Parsing GEOIP file /usr/share/tor/geoip. â â12:12:14 [NOTICE] Tor 0.2.2.34 (git-c55c166e73d500af) opening log file The system is a vServer (2.6.18-028stab093.2) with an uptime of 78 days, so the new kernel version.
- I don't recall if this is the case with Debian or not, but many platforms require that you have the same permissions as the tor process to see its connections. In this case you'd do that by running 'sudo -u debian-tor arm'.
See above. I am using "su -c arm debian-tor" for the new version.The new version is using the control socket "/var/run/tor/control", but no change if I use the control port again.
- If all else fails you can try running 'python /usr/share/arm/test.py', which lets you run through connection resolvers to see which should be working or not.
Well, for the tests I have to activate the control port again. But the first test fails:
Selection: 1
----------------------------------------
proc 126 results 0.0228 seconds
netstat 126 results 0.0288 seconds
Traceback (most recent call last):
File "/usr/share/arm/test.py", line 43, in <module>
connectionResults = connections.getConnections(resolver, "tor", conn.getMyPid())
File "/usr/share/arm/util/connections.py", line 242, in getConnections
results = sysTools.call(cmd)
File "/usr/share/arm/util/sysTools.py", line 330, in call
else: raise errorExc
IOError: 'sockstat' is unavailable
The resolver dump is working for proc, netstat and lsof (root and
debian-tor). I had to run the script with LANG=C, or it would not work in
my German locale. But running arm with LANG=C does not change the
problem.
Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: stse@xxxxxxxxxxxxxxxxxxx | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-talk mailing list tor-talk@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk