[tor-talk] New arm version doesn't show connections
Stephan Seitz
stse+tor at fsing.rootsland.net
Thu Dec 15 08:28:27 UTC 2011
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 at fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20111215/0bb7de83/attachment.pgp>
More information about the tor-talk
mailing list