[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

3.5 mb data segment for clients and location hidden services was Re: tor and Daemantools-0.76



Hi Roger,

Tor was crashing as a simple client binary not as a server, it was providing location hidden services for a VPN and when it went down it was quite noticeable, thus using Daemontools was an obvious answer, the -d3500000 was from djbdns experiments under OpenBSD :).

I did double check the 3.5mb data segment for client and location hidden services , and lastcom|grep tor returns no re invocations of the tor binary. I am working DB conversion and Video services this week so I wont get a chance to try servers settings till I get back to my lab next week(most machines are off pending move of machine room). Chris can you play with this on your servers and determine what is goodness for the data segment in terms of size for a server ?



I have managed to use video surveillance(www.zoneminder.com) via a location hidden service.

ssh port 22

Apache port 80 works

apache 443 works

apache/squid(httpd accelerator)   non-tested

webmin non-ssl  10000 works

webmin-SSL port 10000 doesnt work


usermin port 20000 untested



a tor operator
ps chris I dont seem to be getting core dumps for tor failures.. is there a special switch beyond login.conf. coredumpsize to set this??




tor wrote:

Hi all,
the -d3500000 is perfectly acceptable for running as a hidden service or client... I did say you needed to tune for your usage.
I did NOT post a server example... unfortunately tor on openbsd current seems to just disappear and I have found neither core or assert messages. I am currently working on a systrace version of Daemontools, tor and privoxy for use as a server with settings appropriate for that scenario.


AS I use hidden services as a VPN for certain ssh/http servers this seems to work.

Servers I have also been experimenting with are on FreeBSD5.3, OSX(Tiger and Panther), Debian-unstable as well as miscellaneous others.


and just for you Roger
a 100 second delay on restart:)
---cut here ---
#!/bin/sh
SLEEP=100
sleep $SLEEP
exec 2>&1
exec envuidgid tor envdir ./env softlimit -d3500000 /usr/bin/su tor -c /usr/local/bin/tor
---cut here-






a tor operator

ps chris I dont seem to be getting core dumps for tor failures.. is there a special switch beyond login.conf.



Roger Dingledine wrote:

On Fri, Jul 01, 2005 at 11:48:11AM -0700, tor wrote:


as the current tor Alphas are somewhat unstable under OpenBSD AND I DONT have the time to track down the instability I have elected to put tor under DJ Bernsteins Daemontools to restart as needed.


Do you get cores? Do you get assert failures? Please spend a few moments
to provide a bug report if you have any hints.

Also, please please please put a sleep(100) in your script somewhere.
We had a bug a while ago where people would start their Tor, it would
suck down a directory, kill itself, restart, suck down another directory,
repeat. This was not good for our volunteer's bandwidth. :)




---cut here ---
#!/bin/sh
exec 2>&1
exec envuidgid tor envdir ./env softlimit -d3500000 /usr/bin/su tor -c /usr/local/bin/tor
---cut here---


the -d3500000 should probably be tuned for your usage


Is your instability based on the fact that a 3.5MB data segment is
incredibly too small to run a Tor server? You want another one or two
orders of magnitude more than this.

Thanks,
--Roger