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

(FWD) Problems with Tor in user-mode-linux



[Forwarding since Bernhard isn't on the list, and should have sent
it to or-talk in any case. -RD]

As for why the Tor in CVS may not work, there are known bugs with 2.5/2.6
kernels, epoll, and the new libevent stuff. We're working on those.

As for why Tor 0.0.9.2 memory explodes in user-mode-linux, gosh, I
don't know. Does user-mode-linux not give back memory that's freed?

Is this running as a client or a server? I assume server, since you
have multiple tor processes.

----- Forwarded message from owner-or-dev@xxxxxxxxxxxxx -----

Date: Wed, 19 Jan 2005 07:25:29 +0100 (CET)
From: Bernhard Wiedemann <wiedeman@xxxxxxxxxxxxxxxxxxxxxxx>
To: or-dev@xxxxxxxx

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

I compiled the src.rpm of tor-0.0.9.2-tor.0.suse and ran it on my 
(virtual(user-mode-linux)) machine.
I think, there is something wrong with it, using too much memory after a 
while. Here is what I got after restarting that morning:

 # uname -a
Linux uml4 2.6.9 #2 Sun Dec 12 10:15:27 CET 2004 i686 i686 i386 GNU/Linux
 # date ; free ; netstat -tanp|grep tor|wc -l ; ps ax|grep tor|wc -l
Tue Jan 18 08:34:05 CET 2005
             total       used       free     shared    buffers     cached
Mem:        126156     102652      23504          0      13504      61152
- -/+ buffers/cache:      27996      98160
Swap:        59992       1432      58560
63
6

 # date ; free ; netstat -tanp|grep tor|wc -l ; ps ax|grep tor|grep -v grep |wc -l
Tue Jan 18 10:43:19 CET 2005
             total       used       free     shared    buffers     cached
Mem:        126156     124900       1256          0      13936      69532
- -/+ buffers/cache:      41432      84724
Swap:        59992       1368      58624
102
5

 # date ; free ; netstat -tanp|grep tor|wc -l ; ps ax|grep tor|grep -v grep |wc -l 
Tue Jan 18 19:38:55 CET 2005
             total       used       free     shared    buffers     cached
Mem:        126156     114292      11864          0       1212      16960
- -/+ buffers/cache:      96120      30036
Swap:        59992      15336      44656
168
12

and after killing it came back to normal
 # date ; free ; netstat -tanp|grep tor|wc -l ; ps ax|grep tor|grep -v grep |wc -l
Tue Jan 18 20:03:29 CET 2005
             total       used       free     shared    buffers     cached
Mem:        126156      54148      72008          0       2084      40200
- -/+ buffers/cache:      11864     114292
Swap:        59992       4880      55112
0
0


next I tried a (2 day old) version from CVS:
Jan 18 20:12:40.633 [notice] Tor 0.1.0.0-alpha-cvs opening log file.
Jan 18 20:12:46.908 [notice] circuit_send_next_onion_skin(): Tor has 
successfull
y opened a circuit. Looks like it's working.
Jan 18 21:06:38.986 [notice] conn_close_if_marked(): Conn (addr 
195.64.88.140, fd 80, type Dir, state 1) is being closed, but there are 
still 82 bytes we can't write. (Marked at main.c:575)
Jan 18 21:46:42.763 [notice] conn_close_if_marked(): Conn (addr 
193.138.126.162, fd 55, type Dir, state 1) is being closed, but there are 
still 84 bytes we can't write. (Marked at main.c:575)
Jan 18 22:07:19.514 [err] dnsworker_main(): writing answer failed. Child 
exiting.

and the current version just stopped without even a notice:
Jan 19 06:47:45.454 [notice] do_hup(): Received sighup. Reloading config.
Jan 19 06:47:45.468 [notice] Tor 0.1.0.0-alpha-cvs opening log file.
Jan 19 06:47:45.474 [notice] accounting_set_wakeup_time(): Configured 
hibernation.  This interval begins at 2005-01-08 00:00:00 and ends at 
2005-02-08 00:00:00.  We have no prior estimate for bandwidth, so we will 
start out awake and hibernate when we exhaust our quota.
Jan 19 06:49:51.962 [notice] conn_close_if_marked(): Conn (addr 
66.26.26.105, fd 23, type Dir, state 1) is being closed, but there are 
still 81 bytes we can't write. (Marked at main.c:575)


So the only way of running a tor server for me would be to issue a regular 
(e.g. every 6-12h) tor restart
Maybe increasing RAM would help, but if there is a genuine memory-leak 
this would only delay breakage.
Maybe it is a problem with UML and not your concern... will try out later 
this week on another physical machine.

Bernhard M.
-----BEGIN PGP SIGNATURE-----

iD8DBQFB7f1gSTYLOx37oWQRAoCxAKD+G/sD5188c+jdQbCd8yL/Vvp/QQCgo6pW
dkgqC6m2f5YHMX1Fvzc3k8w=
=Gobg
-----END PGP SIGNATURE-----


----- End forwarded message -----