Unable to login to relay server when Tor is running

[Markus Petersen]

I'm sorry to say that I didn't understand everything you talked about.
Perhaps I can give some output of the various commands and you can
comment on them? This is with Tor not running. I don't have serial
terminal access, as it's a rented VPS.

moo:~# cat /proc/sys/fs/file-max
262144

moo:~# cat /proc/sys/fs/file-nr
1       0       262144

moo:~# ulimit
unlimited

moo:~# ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 595968
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 595968
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Furthermore, I use the shorewall package provided with Debian Lenny,
which sets up some iptables rules. AFAIK, it only sets up default policy
drop and allows the ports I've defined. I could be wrong. I'll investigate.

/Markus

Sven Olaf Kamphuis wrote:
> this sounds like either running out of filedescriptors or some shitty
> iptables anti-ddos script
> 
> each tcp stream = 1 filedescriptor = a few kb of ram (never mind that,
> it's 2010 ;)
> 
> to check/change:
> 
> systemwide maximum:
> 
> a84-22-97-10:~# cat /proc/sys/fs/file-max
> 204135
> 
> file descriptors in use:
> 
> a84-22-97-10:~# cat /proc/sys/fs/file-nr
> 11840   0       204135
> 
> per process and its childs (integrate it into /bin/login or something):
> 
> bash command: ulimit
> tcsh command: limit
> 
> c-command: getrlimit() setrlimit() etc. (for direct integration into the
> /bin/login code and/or crontab on shell servers etc or into the wrapper
> that starts your tor daemon in your case ;)
> 
> a84-22-97-10:~# ulimit -a
> core file size          (blocks, -c) 0
> data seg size           (kbytes, -d) unlimited
> max nice                        (-e) 0
> file size               (blocks, -f) unlimited
> pending signals                 (-i) unlimited
> max locked memory       (kbytes, -l) unlimited
> max memory size         (kbytes, -m) unlimited
> open files                      (-n) 1024
> pipe size            (512 bytes, -p) 8
> POSIX message queues     (bytes, -q) unlimited
> max rt priority                 (-r) 0
> stack size              (kbytes, -s) 8192
> cpu time               (seconds, -t) unlimited
> max user processes              (-u) unlimited
> virtual memory          (kbytes, -v) unlimited
> file locks                      (-x) unlimited
> 
> in all cases, when exceeding either the system or per process-tree
> rlimits, there will be something displayed like fork() resource
> unavailable,
> 
> (ofcourse you already need access at that point so you'd better have a
> local console/serial console already logged in at all times as otherwise
> it can't exec bash while logging in either ;)
> 
> could also be some shitty iptables counter based "ddos filter" which you
> may use (god knows why people use those, cause more trouble than their
> good for, just integrate attack filtering into your server software code
> and make sure "fake" connections take up as less resources as possible
> for as short time as possible, by running proxies in front of the real
> webserver for example that do the connection-per-ip-per-time counting
> and only take a few kb)
> 
> these so-called "ddos protection" scripts using iptables actually cause
> simular problems to what you describe above, not just for tor, for any
> service thats "used a lot", so just don't use them, they're crap ;).
> 
> ports that aren't open don't need "protection" in the first place, and
> you can always just DROP anything you don't want, much easier and less
> chance of it fucking up lets say ssh access.
> 
> 
> On Tue, 12 Jan 2010, Markus Petersen wrote:
> 
>> Dear fellow Tor users,
>>
>> I have a problem that I hope someone is able to help me solving. I want
>> to run a Tor relay (non-exit for the time being) on my VPS. The VPS has
>> got 1GiB of memory, plenty of bandwidth, and I've got about 5TiB of
>> traffic to spare each month, which I'd like to give to the Tor network.
>>
>> The problem is, when the relay has been running for some time (I haven't
>> measured when exactly), I am unable to connect to my server. Neither ssh
>> nor imap-logins work anymore. I tried rate-limiting the relay to
>> 5000kBps and then 1000kBps, with the same results. The only thing that
>> solves it is when I restart the server and disable Tor again.
>>
>> In short: what do I do now? Has anyone got any clue as to what the
>> problem might be? I have a wild guess of the server not being able to
>> have that many TCP connections, but how do I check something like that?
>>
>> Thank you!
>>
>> Regards,
>> Markus
>>
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20100115/786bd3f5/attachment.pgp>