Looking for tor users experiencing crashes

[Robert Watson]

On Mon, 1 May 2006, Robert Watson wrote:

> On Mon, 1 May 2006, Peter Thoenen wrote:
>
>> Its a regression.
>> 
>> See: http://www.freebsd.org/cgi/query-pr.cgi?pr=95180
>> 
>> I am the tor-devel maintainer and not only do I get private emails about 
>> this at least once a week, I am expereincing it myself and also hear about 
>> it on both the OFTC and Freenode tor channels usually every couple days. 
>> Enough folk have brought it up that Arma (lead tor developer) is 
>> considering NOT recommended FBSD 6 as a server platform for tor in server 
>> mode.
>
> It's a pity this wasn't brought to my attention sooner, or there might have 
> been a chance to work on it for 6.1-RELEASE, especially given that it sounds 
> like it has been a moderately long-standing problem.  The first I heard 
> about it was a few days ago from someone else at cam.ac.uk, and since then 
> I've been trying to find information.  Among other things, I attempted to 
> contact you by private e-mail but didn't hear anything back.

ping.

I'd like to work with you to track this down, but am leaving on travel on 
Monday for a week to attend the FreeBSD Developer Summit, BSDCan, etc, in 
Ottawa, Canada, so won't be available online much during that period.  Getting 
some basic information now would be helpful.

Thanks,

Robert N M Watson

>
> Up front, it sounds like we need to do a bit of fact gathering, and if 
> possible, a bit of simplication of the configuration to try and isolate the 
> problem.
>
> Specifically, it sounds like the software configuration on your system is 
> complex, and it would help to be able to narrow things down a bit.  For 
> example, you mention pf being configured on the box.  A first step would be 
> if you could include in the PR a copy of the dmesg output of your box (is it 
> SMP?), as well as the kernel configuration file, rc.conf, loader.conf, etc.
>
> It also sounds like significant load is involved in triggering the bug.  As 
> someone who hasn't used Tor, and without significant bandwidth resources 
> available to test it, a bit of quantification of the type of load would be 
> very helpful.  For example, if I were running in your configuration, would I 
> expect to see 128kbps, 1mbps, 10mbps, 100mbps, 1gbps traffic, etc.  Would it 
> primarily be via the TCP protocol, or other protocols?  Are we talking about 
> a few very busy connections, or tens of thousands of less busy connections? 
> Does the system generate much DNS traffic?  Is the application a 
> multi-process application, a multi-threaded application?  If you run netstat 
> and netstat -na at any given moment, how many open sockets might I see?
>
> Could you send me typical output from top -S, netstat -m, systat -vmstat 1?
>
> If hardware resources are available, it would be good to try running with a 
> simplified configuration, in order to determine that we're not looking at a 
> more complex feature interaction.  For example, if you run on a vanilla 
> kernel, without pf, etc, compiled in or loaded, does the reboot still occur, 
> or does it, for example, require that pf also be loaded?
>
> Do you have a serial console attached to the system?  When the reboot occurs, 
> is there any interesting (or even boring) output on the serial console -- for 
> example, warnings about load, fault messages, etc?  If you are using a serial 
> console but there is no output at all (you immediately see the beginning of 
> the bios or OS boot loader after legitimate looking earlier console output), 
> that's also extremely useful to know.
>
> Are you currently compiling any debugging features in?  Could you try 
> compiling in INVARIANTS?  FWIW, spontaneous hardware poweroff and reboot can 
> be tricky to track down, but we can see what we can do.
>
> I don't have the resources or setup to run Tor in server mode, and can't 
> easily arrange for them.  As such, I need to rely on you (or someone else) to 
> work with me in detail to get this sorted out, so I will be unable to 
> reproduce it directly.
>
> Thanks,
>
> Robert N M Watson
>