Custom Query (26254 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (112 - 114 of 26254)

Ticket Resolution Summary Owner Reporter
#1352 fixed Flood of "Received http status code 404" Warning BarkerJr
Description

Received this warning:

Apr 12 09:43:28.945 [warn] Received http status code 404 ("Not Found") from server '194.109.206.212:80' while fetching "/tor/status/all.z". I'll try again soon.

302 times between 09:43:24.788 and 09:43:28.945. This warning should be throttled.

[Automatically added by flyspray2trac: Operating System: Redhat/CentOS Linux]

#1356 fixed Number of connections increases rapidly. mfo
Description

After upgrading CentOS (RedHat) OpenSSL to version 0.9.8e-12.el5_4.6.i686 (backported) my relay stopped working (see weeek 13 in attached month graph) with no signs of problem in the log.

Then after help from #tor, one authority server administrator saw a problem in my connection attempts. I downgraded my OpenSSL to version 0.9.8e-12.el5_4.1.i686. As a result I got the descriptor published and it seemed to work ok.

Since then the connections has grown and grown to the limits of the relays virtual server capacity leaving it unresponsive (see week 14). Then after restart it regained a too large number of connections very rapid (see attached day graph).

After consulting #tor again (thanks for great help and kindness!) I become aware of that I have lost the stable flag and should try to shut down the relay for a day and then restart configured with 'MaxAdvertisedBandwith to 20KBytes' for a while to regain the stable-flag.

(Tor-relay version 0.2.1.25 (torproject rpm) on Cent-OS 5 in OpenVZ virtual container. Configured bandwitdth 100KB and 200KB burst.)

I will report back if or if not this solves the problem.

[Automatically added by flyspray2trac: Operating System: Redhat/CentOS Linux]

#1357 fixed Generated a synthetic timeout LESS than the current timeout mikeperry stars
Description

Hello,

I think have spoke a few months ago about this bug but don't find any report, so i make one now.

If the FAI have trouble and i.e the network are done a few second, Tor must recalculate the timeout when resume and at this time it create the warning about " Generated a synthetic timeout LESS than the current timeout: 50089ms vs 60000.000000ms using Xm: 1275 a: 0.467440, q: 0.800000".

I running kubuntu karmic 9.10 x86 64 2.6.31-21-generic #59-Ubuntu SMP Wed Mar 24 07:28:27 UTC 2010 x86_64 GNU/Linux

Tor: commit 7221d15acc87d2438aba7e3c261c2fc460479a01 0.2.2.10 alpha-dev but previous version contain the same bug Libevent: commit 3cbca8661f2ad267ca890304a3dc5acefb8ba630

avr. 13 17:08:59.534 [Notice] Network is flaky. No activity for 96 seconds. Temporarily raising timeout to 60s. avr. 13 17:09:19.616 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit) avr. 13 17:09:48.839 [Notice] Network activity has resumed. Resuming circuit timeout calculations. avr. 13 17:09:48.840 [Warning] Generated a synthetic timeout LESS than the current timeout: 50089ms vs 60000.000000ms using Xm: 1275 a: 0.467440, q: 0.800000

Best Regards

SwissTorExit

[Automatically added by flyspray2trac: Operating System: Other Linux]

Note: See TracQuery for help on using queries.