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

Re: Problems running TOR for an extended period



tor_user wrote:
>> http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ServerOS
>>
>>>    I'm not really sure how an application which relays TCP traffic
>>> (albeit encrypting/decrypting it) can consume this amount of RAM. Is it
>>> really normal?
>> On your operating system, yes.
>>
>> If there exists a new version of NetBSD with a reentrant
>> gethostbyname_r(), let us know and we'll special-case it.
> 
> I supposed you could get cron to restart the tor service hourly, or
> daily
> as a workaround.

   That is what I was thinking, but I decided against it since I
wouldn't want to connect through such a system myself (since I would
need to restart it hourly in order to get some kind of stability from
it). My TOR exit node does get a lot of traffic, and in case someone is
downloading something rather large, I don't want to interrupt it
periodically. Sometimes my node can run for a whole day, other times
just half an hour, before crashing. Restarting it each hour feels evil.

   I'd rather like to find a real solution to the problem. Mainly,
getting a working gethostbyname_r(). Btw.. What is the origin of
gethostbyname_r()? Does it exist in all common/mainstream unicies?

   As a side note, I don't understand why the calls to gethostbyname()
can't be mutex'd on BSD systems, rather than just switching over to an
all fork'd design. Are there other calls which are affected as well?

   OS/2 was designed for multi threading from the ground up, but at some
odd times I did actually encounter API:s which weren't thread safe.
Instead of kicking off a bunch of separate processes, I simply protected
those API:s with a mutex semaphore. An ugly workaround, but not as ugly
as launching an army of processes, imho. But then again, I'm unaware if
there are other issues adding to the problem.

-- 
Kind regards,
Jan Danielsson


Attachment: signature.asc
Description: OpenPGP digital signature