Quote:
Originally Posted by unclejed613
the problem is that Vidalia runs an instance of TOR for things like web browsing, etc, and TorChat runs a "portable" instance of TOR, and
|
I'd say that is a problem ;-p Unless Vidalia provides you with something crucial there is absolutely no need to have it run. The application combined with its dependencies has an enormous footprint compared to the TOR binary and TOR as a service runs perfectly on it's own.
Quote:
Originally Posted by unclejed613
while these two usually behave fine, there are times when one or the other instance of TOR for some unknown reason hammers the CPU. this doesn't seem to happen when they are not both running at the same time.
|
What do the instances Vidalia and TOR log files say when that happens? (The torrc man page lists debug options for logging which could be helpful.) Also: can you see the processes state when this happens? And is strace available should it be necessary?
Quote:
Originally Posted by unclejed613
does anybody have enough knowledge about TOR, and specifically TorChat (the stand alone version, not the pidgin plugin) to explain to me how to get TorChat to use the already running instance started by Vidalia?
|
You can send all sorts of diagnostics info to TOR itself with tor-ctrl.sh like "GETINFO status/reachability-succeeded" and get plain text back to parse (that's essentially how Vidalia communicates with TOR under the hood) and trigger some action. You could for example trigger an iptables rule that redirects traffic from one local port to another. But when you're in the middle of a conversation or browsing session switching may cause all sorts of "interesting" side effects like traffic drops and ultimately I'd say it's not TOR that is responsible for switching but the application using it. Before you ponder that let's first see what troubleshooting CPU load brings, OK?
