TOR Not Starting after upgrade
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I've just upgraded to vidalia-bundle-0.2.1.25-0.2.7.exe and now TOR is
not starting at all. I've tried a full uninstall-reinstall with no
changes.
In case it'll help, here's the log of my last try:
Apr 13 22:12:12.625 [Notice] Tor v0.2.1.25. This is experimental
software. Do not rely on it for strong anonymity. (Running on Windows
XP Service Pack 2 [workstation] {terminal services, single user})
Apr 13 22:12:12.625 [Notice] Initialized libevent version
1.4.13-stable using method win32. Good.
Apr 13 22:12:12.625 [Notice] Opening Socks listener on 127.0.0.1:9050
Apr 13 22:12:12.625 [Notice] Opening Control listener on 127.0.0.1:9051
Apr 13 22:12:12.734 [Notice] Parsing GEOIP file.
Apr 13 22:12:16.000 [Debug] conn_read_callback(): socket 1768 wants to
read.
Apr 13 22:12:16.000 [Debug] conn_read_callback(): socket 1768 wants to
read.
Apr 13 22:12:16.000 [Debug] conn_read_callback(): socket 1768 wants to
read.
Apr 13 22:12:36.875 [Debug] conn_read_callback(): socket 1792 wants to
read.
Apr 13 22:12:36.875 [Warning] Problem bootstrapping. Stuck at 5%:
Connecting to directory server. (Socket is not connected [WSAENOTCONN
]; NOROUTE; count 1; recommendation warn)
Apr 13 22:12:36.875 [Debug] conn_close_if_marked(): Cleaning up
connection (fd -1).
Apr 13 22:12:36.875 [Debug] circuit_n_conn_done(): or_conn to
$847B1F850344D7876491A54892F904934E4EB85D/86.59.21.38, status=0
Apr 13 22:12:36.875 [Info] circuit_n_conn_done(): or_conn failed.
Closing circ.
Apr 13 22:12:36.875 [Info] connection_ap_fail_onehop(): Closing
one-hop stream to
'$847B1F850344D7876491A54892F904934E4EB85D/86.59.21.38' because the OR
conn just failed.
Apr 13 22:12:36.875 [Debug] circuit_increment_failure_count():
n_circuit_failures now 1.
Apr 13 22:12:36.875 [Debug] connection_remove(): removing socket -1
(type OR), n_conns now 9
Apr 13 22:12:36.875 [Debug] conn_close_if_marked(): Cleaning up
connection (fd -1).
Apr 13 22:12:36.875 [Debug] connection_remove(): removing socket -1
(type Socks), n_conns now 8
Apr 13 22:12:36.875 [Info] _connection_free(): Freeing linked Socks
connection [waiting for circuit] with 339 bytes on inbuf, 0 on outbuf.
Apr 13 22:12:36.875 [Debug] conn_read_callback(): socket -1 wants to read.
Apr 13 22:12:36.875 [Info] connection_dir_client_reached_eof():
'fetch' response not all here, but we're at eof. Closing.
Apr 13 22:12:36.875 [Debug] conn_close_if_marked(): Cleaning up
connection (fd -1).
Apr 13 22:12:36.875 [Info] connection_dir_request_failed(): Giving up
on directory server at '86.59.21.38'; retrying
Apr 13 22:12:36.875 [Notice] No current certificate known for
authority moria1; launching request.
Apr 13 22:12:36.875 [Notice] No current certificate known for
authority tor26; launching request.
Apr 13 22:12:36.875 [Notice] No current certificate known for
authority dizum; launching request.
Apr 13 22:12:36.875 [Notice] No current certificate known for
authority ides; launching request.
Apr 13 22:12:36.875 [Notice] No current certificate known for
authority gabelmoo; launching request.
Apr 13 22:12:36.875 [Notice] No current certificate known for
authority dannenberg; launching request.
Apr 13 22:12:36.875 [Notice] No current certificate known for
authority urras; launching request.
Apr 13 22:12:36.875 [Info] router_pick_directory_server(): No
reachable router entries for dirservers. Trying them all again.
Apr 13 22:12:36.875 [Info] directory_get_from_dirserver(): No router
found for authority cert fetch; falling back to dirserver list.
Apr 13 22:12:36.875 [Debug] directory_initiate_command_rend():
anonymized 0, use_begindir 1.
Apr 13 22:12:36.875 [Debug] directory_initiate_command_rend():
Initiating authority cert fetch
Apr 13 22:12:36.875 [Info] connection_ap_make_link(): Making internal
direct tunnel to [scrubbed]:443 ...
Apr 13 22:12:36.875 [Debug] connection_add(): new conn type Socks,
socket -1, address (Tor_internal), n_conns 8.
Apr 13 22:12:36.875 [Debug] circuit_get_open_circ_or_launch(): one on
the way!
Apr 13 22:12:36.875 [Info] connection_ap_make_link(): ... application
connection created and linked.
Apr 13 22:12:36.875 [Debug] connection_add(): new conn type Directory,
socket -1, address 194.109.206.212, n_conns 9.
Apr 13 22:12:36.875 [Debug] connection_remove(): removing socket -1
(type Directory), n_conns now 9
Apr 13 22:12:36.875 [Info] _connection_free(): Freeing linked
Directory connection [client reading] with 0 bytes on inbuf, 0 on outbuf.
Apr 13 22:12:36.875 [Debug] conn_read_callback(): socket -1 wants to read.
Apr 13 22:12:36.875 [Info] connection_edge_process_inbuf(): data from
edge while in 'waiting for circuit' state. Leaving it on buffer.
Apr 13 22:12:36.875 [Info] connection_edge_process_inbuf(): data from
edge while in 'waiting for circuit' state. Leaving it on buffer.
Apr 13 22:12:36.875 [Debug] connection_dir_finished_flushing(): client
finished sending command.
Apr 13 22:12:36.984 [Debug] conn_read_callback(): socket 1776 wants to
read.
Re: [or-talk] Re: huge pages, was where are the exit nodes gone?
On Tue, 13 Apr 2010 at 05:58, Scott Bennett wrote: > and straighten us out. Remember that Olaf runs the highest-load-bearing > tor node in our whole network, and there are at least two or four dozen > others that should be considered heavyweight relays that are also on LINUX > systems. ...and some of them are running on old notebooks and the tor process is only a few megabytes in size :-| However, if it turns out that using hugepages in Linux would help larger Tor installations (and "superpages" can be recommended for *BSD systems[0] as well), maybe this can be documented somehwere under doc/ or in the wiki. But let's see how Olaf's experiment turns out. Christian. [0] http://www.freebsd.org/releases/7.2R/relnotes-detailed.html This is disabled by default and can be enabled by setting a loader tunable vm.pmap.pg_ps_enabled to 1. -- BOFH excuse #98: The vendor put the bug there. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: huge pages, was where are the exit nodes gone?
Arjan schrieb: > > http://libhugetlbfs.ozlabs.org/ > From that website: > libhugetlbfs is a library which provides easy access to huge pages of > memory. It is a wrapper for the hugetlbfs file system. Applications can > use huge pages to fulfill malloc() requests without being recompiled by > using LD_PRELOAD. ok, just started tor with this wrapper. Looks like it's working as expected: anonymizer2:~/tmp# lsof -np `cat /var/run/tor/tor.pid` | grep libhugetlbfs.so tor 21716 debian-tor mem REG8,11452825390654 /usr/local/lib64/libhugetlbfs.so anonymizer2:~/tmp# hugeadm --pool-list Size Minimum Current Maximum Default 2097152 100 107 1000* anonymizer2:~/tmp# cat /proc/meminfo | grep -i hugepage HugePages_Total: 107 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:7 Hugepagesize: 2048 kB Keep you posted how it changes performance. Will go to sleep now, Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Problems with Vidalia freezing up
This has just started in the past 3 days. I first had a network drop signal. Called the ip provider and they came out a did a signal test and found it was low and fixed that. However it did not fix my problem. Vidalia has been freezing up several times in the past 4 days. With it progressively getting worse. I have had to reboot the computer 2 times so far today and reboot vidalia 4 times today. In checking the logs, am not able to find any reason for it to lock/freeze up. Naturally it has been frustration since it keeps me from staying online. On the tor logs, there is a number of eventdns issues, but that is not unusual as it corrects it self generally with in less than a couple of seconds. I have run out of ideas. Any ideas on what to look for? I did notice that my inbound and outbound connections have increased a lot and am not sure if that may be the issue causing the freeze. I am on Win Svr 2008rc. Also running Tor ver. 0.2.1.25 and Vidalia ver 0.2.7 . Not sure what else info one might need. Any ideas on what to do next? Thanks, Jon *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: huge pages, was where are the exit nodes gone?
On Tue, 13 Apr 2010 19:10:37 +0200 Arjan wrote: >Scott Bennett wrote: >> BTW, I know that there are *lots* of tor relays running on LINUX >> systems whose operators are subscribed to this list. Don't leave Olaf and >> me here swinging in the breeze. Please jump in with your LINUX expertise >> and straighten us out. > >I'm not an expert, but I managed to perform some google searches. > >http://libhugetlbfs.ozlabs.org/ >>From that website: >libhugetlbfs is a library which provides easy access to huge pages of >memory. It is a wrapper for the hugetlbfs file system. Applications can >use huge pages to fulfill malloc() requests without being recompiled by >using LD_PRELOAD. That does look promising, then. Perhaps Olaf and others can use that method for now. > >Someone is working on transparent hugepage support: >http://thread.gmane.org/gmane.linux.kernel.mm/40182 Thanks much for these URLs, Arjan. I've started going through this thread, but it's a horrendous lot to digest and full of LINUXisms that I know nothing about. I have some errands to run, and then I really *must* get some sleep. Maybe late tonight I'll continue reading. In the meantime, perhaps some adventurous relay operator using LINUX could begin experimenting with the libhugetlbfs-in-LD_PRELOAD method to see whether tor functions okay with it and then report the results back to the list. I'll be offline for at least 10 - 12 hours. Best of luck! Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: huge pages, was where are the exit nodes gone?
Scott Bennett wrote: > BTW, I know that there are *lots* of tor relays running on LINUX > systems whose operators are subscribed to this list. Don't leave Olaf and > me here swinging in the breeze. Please jump in with your LINUX expertise > and straighten us out. I'm not an expert, but I managed to perform some google searches. http://libhugetlbfs.ozlabs.org/ >From that website: libhugetlbfs is a library which provides easy access to huge pages of memory. It is a wrapper for the hugetlbfs file system. Applications can use huge pages to fulfill malloc() requests without being recompiled by using LD_PRELOAD. Someone is working on transparent hugepage support: http://thread.gmane.org/gmane.linux.kernel.mm/40182 *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: huge pages, was where are the exit nodes gone?
Scott Bennett wrote: > > BTW, I know that there are *lots* of tor relays running on LINUX > systems whose operators are subscribed to this list. Don't leave Olaf and > me here swinging in the breeze. Please jump in with your LINUX expertise > and straighten us out. in case of someone being interested in blutmagie exit's low level stats: http://torstatus.blutmagie.de/public_mrtg regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: huge pages, was where are the exit nodes gone?
On Tue, 13 Apr 2010 18:15:18 +0200 Olaf Selke wrote: >Scott Bennett wrote: > >> Now that you've had tor running for a while, what does a >> "cat /proc/meminfo | grep -i hugepage" show you? Also, 126 such pages >> equal 256 MB of memory. Is that really enough to hold your entire tor >> process when it's going full tilt? I thought I had seen you post items >> here in the past that said it was taking well over 1 GB and approaching >> 2 GB. > >tor process crashed with out of memory error ;-) >Apr 13 11:06:39.419 [err] Out of memory on malloc(). Dying. Hmm. Looks like you need to raise its stack segment and/or data segment size limit(s). > >After restarting the tor process HugePages_Total and HugePages_Free >still had a value of 126, so I assume tor didn't use them. Eventually I >disabled them. > Well, the first number shouldn't change. If tor had already quit, the the HugePages_Free value, even if some had been allocated/reserved, should have reverted to the HugePages_Total value anyway, so what you saw there should really be no surprise. Have you found anything yet about huge pages in the LINUX man pages or other documentation? It seems to me that the documentation kind of has to cover the use of huge pages *somewhere*. Does LINUX have anything like apropos(1) for finding things by keystring in the man page collection? Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: huge pages, was where are the exit nodes gone?
Scott Bennett wrote: > Now that you've had tor running for a while, what does a > "cat /proc/meminfo | grep -i hugepage" show you? Also, 126 such pages > equal 256 MB of memory. Is that really enough to hold your entire tor > process when it's going full tilt? I thought I had seen you post items > here in the past that said it was taking well over 1 GB and approaching > 2 GB. tor process crashed with out of memory error ;-) Apr 13 11:06:39.419 [err] Out of memory on malloc(). Dying. After restarting the tor process HugePages_Total and HugePages_Free still had a value of 126, so I assume tor didn't use them. Eventually I disabled them. cheers Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: huge pages, was where are the exit nodes gone?
On Tue, 13 Apr 2010 05:16:33 -0500 (CDT) I wrote: > On Tue, 13 Apr 2010 11:04:36 +0200 Olaf Selke >wrote: >>Scott Bennett wrote: >> >>> Either I forgot (probable) or you didn't mention before (less probable) >>> that you had moved it to a newer machine. Whatever you're running it on, >>> superpages or LINUX's "huge" pages ought to speed tor up considerably by >>> drastically reducing TLB misses. (I wasn't suggesting that you revert to >>> older hardware. I was thinking that you were still running tor on the Xeon- >>> based machine.) >> >>I just setup hugepages (1024 pages a 2 MB) according this hint >>http://www.pythian.com/news/1326/performance-tuning-hugepages-in-linux/ > > Very interesting article. Thanks for the URL. Of course, not being >a LINUX user, I have no idea what the acronyms for various LINUX kernel >features mean, and I have mercifully been free of any involvement with >Oracle for ~17 years, so ditto for the Oracle stuff. :-) > One matter of concern, though, is the mention of a page size of 2 MB. >Intel x86-style CPUs offer a 2 MB page size *only* for instruction (a.k.a. >text) segments, not for data or stack segments, so I'm not sure what LINUX >is doing with that. (See also the last line of the following bit of >output.) >> >>anonymizer2:~# echo 1024 > /proc/sys/vm/nr_hugepages >>anonymizer2:~# cat /proc/meminfo | grep -i hugepage >>HugePages_Total: 126 ^^^ Apparently, telling it reserve 1024 huge pages didn't take. I guess you'll have to dig into the LINUX documentation a bit to find out what's up with that. >>HugePages_Free: 126 >>HugePages_Rsvd:0 >>HugePages_Surp:0 >>Hugepagesize: 2048 kB >> >>Does tor process automagically take advantage from hugepages after >>restarting the process or has tor source code to be modified? >> > Olaf, I honestly don't know. I had not seen the page for which you >provided a URL, and it is more recent than what I had read about LINUX's >huge pages before. Those older articles clearly stated that a program >had to reserve/designate its memory as huge pages *explicitly*, but it's >possible that usage is now more automatic. However, part of the final >sentence in the article's summary section stands out to me: > > "If your database is running in LINUX *and has HugePages capability* > [emphasis mine --SB], there is no reason not to use it." > >That suggests to me that the application (tor, in this case) must tell >the LINUX kernel which page size it wants for its memory. Whether it >also has to specify address ranges explicitly to be so mapped, I haven't >the foggiest idea. But even if the application does have to tell the >kernel something, it ought to be fairly trivial to add to tor's startup >code. Start out by overestimating (assuming there is adequate real >memory on the system to play with) how much tor will need at its maximum >size, then decrease it, perhaps a bit at a time in successive recompilations, >until it only minimally exceeds tor's high-water mark. BTW, I know that there are *lots* of tor relays running on LINUX systems whose operators are subscribed to this list. Don't leave Olaf and me here swinging in the breeze. Please jump in with your LINUX expertise and straighten us out. Remember that Olaf runs the highest-load-bearing tor node in our whole network, and there are at least two or four dozen others that should be considered heavyweight relays that are also on LINUX systems. It is in every LINUX+tor user's interest to help Olaf and others running tor nodes on LINUX systems here to make sure all of those systems are getting the performance benefits of smaller page tables for their tor processes (provided those systems have adequate real memory, which I would bet most of them do). I've worked with UNIX for decades, but have never used a LINUX system. Olaf shouldn't have to depend solely upon someone who doesn't really know much of what he's writing about to get his blutmagie tor node running with LINUX huge pages when there are so many LINUX system experts on this list. >[soapbox: on] > [Unless you have other applications also using that machine, this would >probably all be made so much easier by just trying out PC-BSD 8.0 because a >one-line entry in /boot/loader.conf would take care of superpages for you >automatically. PC-BSD is the install-and-go version for both new users who >need to be able to use the system right away before learning much and casual >users who have no interest in learning much about FreeBSD. This special >packaging of the system is designed to allow both groups, who might >otherwise find it beyond the effort they were willing or able to put into >it, to get its benefits.] >[soapbox: off] > Now that you've had tor running for a while, what does a >"cat /proc/meminfo | grep -i hugepage" show you? Also, 126 such pages >equal 256 MB of memory. Is that real
Re: huge pages, was where are the exit nodes gone?
On Tue, 13 Apr 2010 11:04:36 +0200 Olaf Selke wrote: >Scott Bennett wrote: > >> Either I forgot (probable) or you didn't mention before (less probable) >> that you had moved it to a newer machine. Whatever you're running it on, >> superpages or LINUX's "huge" pages ought to speed tor up considerably by >> drastically reducing TLB misses. (I wasn't suggesting that you revert to >> older hardware. I was thinking that you were still running tor on the Xeon- >> based machine.) > >I just setup hugepages (1024 pages a 2 MB) according this hint >http://www.pythian.com/news/1326/performance-tuning-hugepages-in-linux/ Very interesting article. Thanks for the URL. Of course, not being a LINUX user, I have no idea what the acronyms for various LINUX kernel features mean, and I have mercifully been free of any involvement with Oracle for ~17 years, so ditto for the Oracle stuff. :-) One matter of concern, though, is the mention of a page size of 2 MB. Intel x86-style CPUs offer a 2 MB page size *only* for instruction (a.k.a. text) segments, not for data or stack segments, so I'm not sure what LINUX is doing with that. (See also the last line of the following bit of output.) > >anonymizer2:~# echo 1024 > /proc/sys/vm/nr_hugepages >anonymizer2:~# cat /proc/meminfo | grep -i hugepage >HugePages_Total: 126 >HugePages_Free: 126 >HugePages_Rsvd:0 >HugePages_Surp:0 >Hugepagesize: 2048 kB > >Does tor process automagically take advantage from hugepages after >restarting the process or has tor source code to be modified? > Olaf, I honestly don't know. I had not seen the page for which you provided a URL, and it is more recent than what I had read about LINUX's huge pages before. Those older articles clearly stated that a program had to reserve/designate its memory as huge pages *explicitly*, but it's possible that usage is now more automatic. However, part of the final sentence in the article's summary section stands out to me: "If your database is running in LINUX *and has HugePages capability* [emphasis mine --SB], there is no reason not to use it." That suggests to me that the application (tor, in this case) must tell the LINUX kernel which page size it wants for its memory. Whether it also has to specify address ranges explicitly to be so mapped, I haven't the foggiest idea. But even if the application does have to tell the kernel something, it ought to be fairly trivial to add to tor's startup code. Start out by overestimating (assuming there is adequate real memory on the system to play with) how much tor will need at its maximum size, then decrease it, perhaps a bit at a time in successive recompilations, until it only minimally exceeds tor's high-water mark. [soapbox: on] [Unless you have other applications also using that machine, this would probably all be made so much easier by just trying out PC-BSD 8.0 because a one-line entry in /boot/loader.conf would take care of superpages for you automatically. PC-BSD is the install-and-go version for both new users who need to be able to use the system right away before learning much and casual users who have no interest in learning much about FreeBSD. This special packaging of the system is designed to allow both groups, who might otherwise find it beyond the effort they were willing or able to put into it, to get its benefits.] [soapbox: off] Now that you've had tor running for a while, what does a "cat /proc/meminfo | grep -i hugepage" show you? Also, 126 such pages equal 256 MB of memory. Is that really enough to hold your entire tor process when it's going full tilt? I thought I had seen you post items here in the past that said it was taking well over 1 GB and approaching 2 GB. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
huge pages, was where are the exit nodes gone?
Scott Bennett wrote: > Either I forgot (probable) or you didn't mention before (less probable) > that you had moved it to a newer machine. Whatever you're running it on, > superpages or LINUX's "huge" pages ought to speed tor up considerably by > drastically reducing TLB misses. (I wasn't suggesting that you revert to > older hardware. I was thinking that you were still running tor on the Xeon- > based machine.) I just setup hugepages (1024 pages a 2 MB) according this hint http://www.pythian.com/news/1326/performance-tuning-hugepages-in-linux/ anonymizer2:~# echo 1024 > /proc/sys/vm/nr_hugepages anonymizer2:~# cat /proc/meminfo | grep -i hugepage HugePages_Total: 126 HugePages_Free: 126 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB Does tor process automagically take advantage from hugepages after restarting the process or has tor source code to be modified? regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Need a full description of 'Use New Identity'
On Tue, 13 Apr 2010 12:49:33 +0530 emigrant wrote: >i need a full explation or a link which talks about 'Use new identity'. >thanks a lot. The answer is in the documentation, but I don't remember off the top of my head where, so I don't have a URL for you. It tells your client, basically, to "mark all existing circuits as being too old to use for new streams" and to "build three new circuits proactively". Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Need a full description of 'Use New Identity'
hi all, i need a full explation or a link which talks about 'Use new identity'. thanks a lot. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
