Re: [freenet-support] Freenet hangs and restarts shortly after startup
On Monday 08 Oct 2012 22:06:59 guido wrote: Nothing obvious there. Are you sure it was using heavy CPU at the time? It's always using this much CPU, including at that time. I checked. (With top) If so it might be a garbage collection issue how much memory is Freenet allowed in wrapper.conf? wrapper.java.maxmemory is set to 1095. I can find no other setting related to memory limits in there. Here's the entire file: wrapper.java.command=java wrapper.working.dir=../ wrapper.java.mainclass=freenet.node.NodeStarter wrapper.java.classpath.1=freenet.jar wrapper.java.classpath.2=freenet-ext.jar wrapper.java.library.path.1=lib wrapper.java.initmemory=60 # Increased because of slot filters in 1385 wrapper.java.maxmemory=1095 wrapper.java.additional.1=-Dnetworkaddress.cache.ttl=0 wrapper.java.additional.2=-Dnetworkaddress.cache.negative.ttl=0 wrapper.java.additional.3=-enableassertions:freenet Okay, add this line here: wrapper.java.additional.4=-Xloggc:freenet.loggc Then shut down and start up Freenet, and watch freenet.loggc. Are you seeing a lot of Full GC ? signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Noderef leaking interface ID
On Monday 08 Oct 2012 15:35:17 Pascal wrote: In fact, if a node attempts to use the interface ID in the noderef as a local zone index then the IPv6 connection will fail if the interface IDs do not match, as zone indices override the routing table if specified. For example: Node A has an IP address of 2001:db8::1 on interface 1. Node A will publish 2001:db8::1%1 in its noderef. Node B's IPv6 default gateway is on its interface 2. If node B attempts to contact node A at 2001:db8::1%1 the request will fail. Node B must use 2001:db8::1 or 2001:db8::1%2 to contact node A, the former using the local routing table, the later specifying the local zone index. So this breaks IPv6 support? Potentially or usually? signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Noderef leaking interface ID
On Monday 08 Oct 2012 15:35:17 Pascal wrote: In fact, if a node attempts to use the interface ID in the noderef as a local zone index then the IPv6 connection will fail if the interface IDs do not match, as zone indices override the routing table if specified. For example: Node A has an IP address of 2001:db8::1 on interface 1. Node A will publish 2001:db8::1%1 in its noderef. Node B's IPv6 default gateway is on its interface 2. If node B attempts to contact node A at 2001:db8::1%1 the request will fail. Node B must use 2001:db8::1 or 2001:db8::1%2 to contact node A, the former using the local routing table, the later specifying the local zone index. -Pascal Filed bug: https://bugs.freenetproject.org/view.php?id=5515 I may not be able to test it ... I will try to look at it soon though ... signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] freenet.node.FSParseException: Unable to load address tracker table, assuming an unclean shutdown
On Sunday 07 Oct 2012 04:36:41 Ken T Takusagawa wrote: On Sat, 6 Oct 2012, Steve Dougherty wrote: Does deleting or renaming the file bootID (in the directory Freenet is installed in) allow the node to start or result in a different error? Same error, and the node does not start. The value X in Last ID was X but stored -6743938579771040868 does keep changing. It seems to loop: emitting the error and stack trace, closing, renaming, and compressing the log file, then emitting the error (with different X) again into a fresh log file. That does not make sense. That error is irrelevant. I assume it's the last thing it says in logs/freenet-latest.log? What does it say in wrapper.log? signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Freenet hangs and restarts shortly after startup
Am Dienstag, 9. Oktober 2012, 10:33:35 schrieb Matthew Toseland: On Monday 08 Oct 2012 22:06:59 guido wrote: Nothing obvious there. Are you sure it was using heavy CPU at the time? It's always using this much CPU, including at that time. I checked. (With top) If so it might be a garbage collection issue how much memory is Freenet allowed in wrapper.conf? wrapper.java.maxmemory is set to 1095. I can find no other setting related to memory limits in there. Here's the entire file: wrapper.java.command=java wrapper.working.dir=../ wrapper.java.mainclass=freenet.node.NodeStarter wrapper.java.classpath.1=freenet.jar wrapper.java.classpath.2=freenet-ext.jar wrapper.java.library.path.1=lib wrapper.java.initmemory=60 # Increased because of slot filters in 1385 wrapper.java.maxmemory=1095 wrapper.java.additional.1=-Dnetworkaddress.cache.ttl=0 wrapper.java.additional.2=-Dnetworkaddress.cache.negative.ttl=0 wrapper.java.additional.3=-enableassertions:freenet Okay, add this line here: wrapper.java.additional.4=-Xloggc:freenet.loggc Then shut down and start up Freenet, and watch freenet.loggc. Are you seeing a lot of Full GC ? How much is a lot? After ~30 minutes of uptime, I get this: $ grep Full freenet.loggc 173.713: [Full GC 59569K-30609K(66752K), 0.1119400 secs] 194.924: [Full GC 42692K-42510K(84224K), 0.1144190 secs] 224.924: [Full GC 1K-66538K(116160K), 0.0961980 secs] 233.162: [Full GC 78622K-76056K(129216K), 0.1531610 secs] 276.978: [Full GC 110170K-101941K(193472K), 0.1233060 secs] 300.933: [Full GC 147726K-111491K(230784K), 0.1306090 secs] 327.116: [Full GC 160279K-130951K(279360K), 0.1293510 secs] 355.853: [Full GC 172159K-124036K(306432K), 0.1917980 secs] 380.778: [Full GC 159951K-137945K(351552K), 0.1342150 secs] 815.527: [Full GC 186389K-126615K(232320K), 0.1548210 secs] 927.181: [Full GC 165409K-116784K(307136K), 0.1476340 secs] Guido ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Datastore resize
On Friday 05 Oct 2012 15:00:13 Jep wrote: Matthew Toseland: On Thursday 04 Oct 2012 21:12:36 Jep wrote: Datastore(PUBKEY-cache) maintenance in progress: xxx/xxx. We have changed the datastore so that it will cause less load on your computer (particularly disk accesses), but we have to rebuild the indexes first.. This is coming up every time I have to reboot. Who or what is 'we', is this planned, and if so, why haven't I anywhere seen it announced that this is supposed to happen? Because it was implemented months ago? And is it intended we do this each and every bootup? Also months ago I haven't seen anything on it. No, clearly not. It's supposed to switch to the slot filters and then live happily ever after. Hmmm ... Apparently we use the same message when migrating to slot filters from bloom filters as we do when rebuilding because of an unclean shutdown. I have fixed this in the source, it will be included in the next build; we will use a different message if the .slotfilter file doesn't exist. In your datastore/ folder you should have the following .slotfilter files, as well as other stuff: CHK-cache.slotfilter CHK-clientcache.slotfilter CHK-store.slotfilter PUBKEY-cache.slotfilter PUBKEY-clientcache.slotfilter PUBKEY-store.slotfilter SSK-cache.slotfilter SSK-clientcache.slotfilter SSK-store.slotfilter Do all these files exist? If so then it probably isn't migrating - it's probably rebuilding because of an unclean shutdown. In other words, Freenet has been killed by the wrapper because of taking too long to shut down, or you had a power cut, or pushed the power button or something. wrapper.log may reveal whether Freenet is regularly having problems shutting down? signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Installation Difficulties
On Wednesday 03 Oct 2012 23:37:04 Seth Roberts wrote: Hi, I have been having trouble installing Freenet on my Mac. I have Mac OS X 10.6.8 with a 2.4GHz Intel Core 2Duo Processor I tried installing, but came across a few problems detailed in the attached screenshots. I have no idea what the problem is, but have forwarded this to our mac expert. signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Freenet hangs and restarts shortly after startup
On Tuesday 09 Oct 2012 13:10:43 guido wrote:
Am Dienstag, 9. Oktober 2012, 10:33:35 schrieb Matthew Toseland:
On Monday 08 Oct 2012 22:06:59 guido wrote:
Nothing obvious there. Are you sure it was using heavy CPU at the time?
It's always using this much CPU, including at that time. I checked. (With
top)
If so it might be a garbage collection issue
how much memory is Freenet allowed in wrapper.conf?
wrapper.java.maxmemory is set to 1095. I can find no other setting related
to memory limits in there.
Here's the entire file:
wrapper.java.command=java
wrapper.working.dir=../
wrapper.java.mainclass=freenet.node.NodeStarter
wrapper.java.classpath.1=freenet.jar
wrapper.java.classpath.2=freenet-ext.jar
wrapper.java.library.path.1=lib
wrapper.java.initmemory=60
# Increased because of slot filters in 1385
wrapper.java.maxmemory=1095
wrapper.java.additional.1=-Dnetworkaddress.cache.ttl=0
wrapper.java.additional.2=-Dnetworkaddress.cache.negative.ttl=0
wrapper.java.additional.3=-enableassertions:freenet
Okay, add this line here:
wrapper.java.additional.4=-Xloggc:freenet.loggc
Then shut down and start up Freenet, and watch freenet.loggc. Are you seeing
a lot of Full GC ?
How much is a lot? After ~30 minutes of uptime, I get this:
$ grep Full freenet.loggc
173.713: [Full GC 59569K-30609K(66752K), 0.1119400 secs]
194.924: [Full GC 42692K-42510K(84224K), 0.1144190 secs]
224.924: [Full GC 1K-66538K(116160K), 0.0961980 secs]
233.162: [Full GC 78622K-76056K(129216K), 0.1531610 secs]
276.978: [Full GC 110170K-101941K(193472K), 0.1233060 secs]
300.933: [Full GC 147726K-111491K(230784K), 0.1306090 secs]
327.116: [Full GC 160279K-130951K(279360K), 0.1293510 secs]
355.853: [Full GC 172159K-124036K(306432K), 0.1917980 secs]
380.778: [Full GC 159951K-137945K(351552K), 0.1342150 secs]
815.527: [Full GC 186389K-126615K(232320K), 0.1548210 secs]
927.181: [Full GC 165409K-116784K(307136K), 0.1476340 secs]
Well each one lasts less than a seconf and they are happening much less than
once per second. So no, that's not a lot.
= It's not a garbage collection issue.
I guess you could get a few more stack dumps and send me them? Make sure that
it's using loads of CPU at the time.
signature.asc
Description: This is a digitally signed message part.
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
[freenet-support] Freenet 0.7.5 build 1418
Freenet 0.7.5 build 1418 is now available, please upgrade, it will be mandatory on the 30th of October (3 weeks). There are many changes, including: - German and Japanese translation updates. - Lots of minor tidy ups etc. - Many internal changes to make hashtable exhaustion CPU DoS attacks impossible. - New versions of several plugins, and better compatibility mode detection (used by some parts of KeyUtils). - Changes relating to downloading filtered files, including a better warning message including the MIME type, and check for the file extension not matching the filtered MIME type. - Extend startup timeouts while trying to gather entropy. - Request UIDs are now per-type i.e. separate for CHK requests vs SSK inserts. This should fractionally improve security against some attacks. (This is why it is eventually mandatory) - Lots of work on various themes, with several new variants. Please let me know if you find any bugs! Also, please verify it with the verify scripts if you can. Thanks. signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] [freenet-dev] Freenet 0.7.5 build 1418
On Tuesday 09 Oct 2012 22:45:55 Matthew Toseland wrote: Freenet 0.7.5 build 1418 is now available, please upgrade, it will be mandatory on the 30th of October (3 weeks). There are many changes, including: - German and Japanese translation updates. - Lots of minor tidy ups etc. - Many internal changes to make hashtable exhaustion CPU DoS attacks impossible. - New versions of several plugins, and better compatibility mode detection (used by some parts of KeyUtils). - Changes relating to downloading filtered files, including a better warning message including the MIME type, and check for the file extension not matching the filtered MIME type. - Extend startup timeouts while trying to gather entropy. - Request UIDs are now per-type i.e. separate for CHK requests vs SSK inserts. This should fractionally improve security against some attacks. (This is why it is eventually mandatory) - Lots of work on various themes, with several new variants. Please let me know if you find any bugs! Also, please verify it with the verify scripts if you can. Thanks. 1419 is out. Sorry about that. The Connections page was broken by a combination of 1) me finally getting around to uploading an up to date IpToCountry.dat on releasing a build, 2) the creation of the country of South Sudan since the last version was downloaded, and 3) poor handling of unexpected country codes. #3 is a bug, it is now fixed. signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
