[freenet-support] Re: Freenet daemon dies
Harrison Smith writes: > > Harrison Smith ...> writes: > > > No luck. I fiddled with the -Xmx option; I even downgraded to jre 1.4.2 > > blackdown - but it still randomly crashes without explanation. I didn't any > > hs_err_pid_ files, either. If you want to see any of my logs, just tell -- snip -- > java.io.IOException: Attempt to use a released TempFileBucket: /root/f > \reenet/store/temp/tbf_11b51af > at freenet.support.SpyOutputStream.checkValid(SpyOutputStream > \.java:29) > at freenet.support.SpyOutputStream.(SpyOutputStream.java -- snip -- I don't know why this happens, but it has been reported before. If these errors occur immediately before/during the screwup than they presumably indicate it's the problem. Unfortunately if it's a bug it's unlikely to get fixed because development is happening on 0.7 ... You could try deleting the "index" file in the store/ directory, which will make freenet rebuild it. Actually it should be better to set "useDSIndex=false" in freenet.conf, which is a good performance idea for permanent/semi-permanent nodes anyway because it causes less CPU usage in the long run at the cost of longer startup times. I don't know if this will solve this problem though :-/ Oh, and Sun's JRE is recommended over Blackdown's generally speaking ... I know they're sort of derived from the same codebase but Sun's is more up to date and has bugfixes they don't bother telling the Blackdown people about (it's a pretty stupid arrangement really.) Bob
[freenet-support] Re: Freenet daemon dies
Harrison Smith <[EMAIL PROTECTED]> writes: > > Harrison Smith ...> writes: > > > No luck. I fiddled with the -Xmx option; I even downgraded to jre 1.4.2 > > blackdown - but it still randomly crashes without explanation. I didn't any > > hs_err_pid_ files, either. If you want to see any of my logs, just tell -- snip -- > java.io.IOException: Attempt to use a released TempFileBucket: /root/f > \reenet/store/temp/tbf_11b51af > at freenet.support.SpyOutputStream.checkValid(SpyOutputStream > \.java:29) > at freenet.support.SpyOutputStream.(SpyOutputStream.java -- snip -- I don't know why this happens, but it has been reported before. If these errors occur immediately before/during the screwup than they presumably indicate it's the problem. Unfortunately if it's a bug it's unlikely to get fixed because development is happening on 0.7 ... You could try deleting the "index" file in the store/ directory, which will make freenet rebuild it. Actually it should be better to set "useDSIndex=false" in freenet.conf, which is a good performance idea for permanent/semi-permanent nodes anyway because it causes less CPU usage in the long run at the cost of longer startup times. I don't know if this will solve this problem though :-/ Oh, and Sun's JRE is recommended over Blackdown's generally speaking ... I know they're sort of derived from the same codebase but Sun's is more up to date and has bugfixes they don't bother telling the Blackdown people about (it's a pretty stupid arrangement really.) Bob ___ 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:[EMAIL PROTECTED]
[freenet-support] Re: Freenet daemon dies
Harrison Smith writes:
> No luck. I fiddled with the -Xmx option; I even downgraded to jre 1.4.2
> blackdown - but it still randomly crashes without explanation. I didn't any
> hs_err_pid_ files, either. If you want to see any of my logs, just tell me
> where they are, and I'll share them.
Okay, I left my telnet session open a while longer, and when freenet started
acting up, a lot of stuff showed up right on the terminal. This is what it said:
("\" means continuation of the previous line)
java.io.IOException: Attempt to use a released TempFileBucket: /root/f
\reenet/store/temp/tbf_11b51af
at freenet.support.SpyOutputStream.checkValid(SpyOutputStream
\.java:29)
at freenet.support.SpyOutputStream.(SpyOutputStream.java
\:48)
at freenet.support.TempFileBucket.getOutputStream(TempFileBuck
\et.java:133)
at freenet.client.SegmentOutputStream.nextBucket(SegmentOutput
\Stream.java:280)
at freenet.client.SegmentOutputStream.write(SegmentOutputStrea
\m.java:192)
at java.io.OutputStream.write(OutputStream.java:58)
at freenet.crypt.DecipherOutputStream.write(DecipherOutputStre
\am.java:40)
at freenet.client.InternalClient$InternalFeedbackToken$Interna
\lDataChunkOutputStream.sendChunk(InternalClient.java:279)
at freenet.support.io.DataChunkOutputStream.write(DataChunkOut
\putStream.java:43)
at freenet.support.io.CBStripOutputStream.write(CBStripOutputS
\tream.java:41)
at freenet.OutputStreamTrailerWriter.writeTrailing(OutputStrea
\mTrailerWriter.java:19)
at freenet.node.states.data.SendData.sendWritePadding(SendData
\.java:536)
at freenet.node.states.data.SendData.received(SendData.java:27
\0)
at freenet.node.StateChain.received(StateChain.java:177)
at freenet.node.StateChain.received(StateChain.java:61)
at freenet.node.StateChainManagingMessageHandler$ChainContaine
\r.run(StateChainManagingMessageHandler.java:335)
at freenet.node.StateChainManagingMessageHandler$ChainContaine
\r.received(StateChainManagingMessageHandler.java:288)
at freenet.node.StateChainManagingMessageHandler$ChainContaine
\r.access$100(StateChainManagingMessageHandler.java:207)
at freenet.node.StateChainManagingMessageHandler.handle(StateC
\hainManagingMessageHandler.java:99)
at freenet.Ticker$Event.run(Ticker.java:325)
at freenet.thread.YThreadFactory$YThread.run(YThreadFactory.ja
\va:285)
java.io.IOException: Attempt to use a released TempFileBucket: /root/f
\reenet/store/temp/tbf_11b51af
at freenet.support.SpyOutputStream.checkValid(SpyOutputStream.
\java:29)
at freenet.support.SpyOutputStream.(SpyOutputStream.java
\:48)
at freenet.support.TempFileBucket.getOutputStream(TempFileBuck
\et.java:133)
at freenet.client.SegmentOutputStream.nextBucket(SegmentOutput
\Stream.java:280)
at freenet.client.SegmentOutputStream.write(SegmentOutputStrea
\m.java:192)
at java.io.OutputStream.write(OutputStream.java:58)
at freenet.crypt.DecipherOutputStream.write(DecipherOutputStre
\am.java:40)
at freenet.client.InternalClient$InternalFeedbackToken$Interna
\lDataChunkOutputStream.sendChunk(InternalClient.java:279)
at freenet.support.io.DataChunkOutputStream.write(DataChunkOut
\putStream.java:43)
at freenet.support.io.CBStripOutputStream.write(CBStripOutputS
\tream.java:41)
at freenet.OutputStreamTrailerWriter.writeTrailing(OutputStrea
\mTrailerWriter.java:19)
at freenet.node.states.data.SendData.sendWritePadding(SendData
\.java:536)
at freenet.node.states.data.SendData.received(SendData.java:27
\0)
at freenet.node.StateChain.received(StateChain.java:177)
at freenet.node.StateChain.received(StateChain.java:61)
at freenet.node.StateChainManagingMessageHandler$ChainContaine
\r.run(StateChainManagingMessageHandler.java:335)
at freenet.node.StateChainManagingMessageHandler$ChainContaine
\r.received(StateChainManagingMessageHandler.java:288)
at freenet.node.StateChainManagingMessageHandler$ChainContaine
\r.access$100(StateChainManagingMessageHandler.java:207)
at freenet.node.StateChainManagingMessageHandler.handle(StateC
\hainManagingMessageHandler.java:99)
at freenet.Ticker$Event.run(Ticker.java:325)
at freenet.thread.YThreadFactory$YThread.run(YThreadFactory.ja
\va:285)
port.SpyOutputStream.checkValid(SpyOutputStream.java:29)
at freenet.support.SpyOutputStream.(SpyOutputStream.java
\:48)
at freenet.support.TempFileBucket.getOutputStream(TempFileBuck
\et.java:133)
at freenet.client.SegmentOutputStream.nextBucket(SegmentOutput
\Stream.java:280)
at freenet.client.SegmentOutputStream.write(SegmentOutputStrea
\m.java:192)
at java.io.OutputStream.write(OutputStream.java:58)
at freenet.crypt.DecipherOutputStream.write(DecipherOutputStre
\am.java:40)
at freenet.client.InternalClien
[freenet-support] Re: Freenet daemon dies
Harrison Smith <[EMAIL PROTECTED]> writes:
> No luck. I fiddled with the -Xmx option; I even downgraded to jre 1.4.2
> blackdown - but it still randomly crashes without explanation. I didn't any
> hs_err_pid_ files, either. If you want to see any of my logs, just tell me
> where they are, and I'll share them.
Okay, I left my telnet session open a while longer, and when freenet started
acting up, a lot of stuff showed up right on the terminal. This is what it said:
("\" means continuation of the previous line)
java.io.IOException: Attempt to use a released TempFileBucket: /root/f
\reenet/store/temp/tbf_11b51af
at freenet.support.SpyOutputStream.checkValid(SpyOutputStream
\.java:29)
at freenet.support.SpyOutputStream.(SpyOutputStream.java
\:48)
at freenet.support.TempFileBucket.getOutputStream(TempFileBuck
\et.java:133)
at freenet.client.SegmentOutputStream.nextBucket(SegmentOutput
\Stream.java:280)
at freenet.client.SegmentOutputStream.write(SegmentOutputStrea
\m.java:192)
at java.io.OutputStream.write(OutputStream.java:58)
at freenet.crypt.DecipherOutputStream.write(DecipherOutputStre
\am.java:40)
at freenet.client.InternalClient$InternalFeedbackToken$Interna
\lDataChunkOutputStream.sendChunk(InternalClient.java:279)
at freenet.support.io.DataChunkOutputStream.write(DataChunkOut
\putStream.java:43)
at freenet.support.io.CBStripOutputStream.write(CBStripOutputS
\tream.java:41)
at freenet.OutputStreamTrailerWriter.writeTrailing(OutputStrea
\mTrailerWriter.java:19)
at freenet.node.states.data.SendData.sendWritePadding(SendData
\.java:536)
at freenet.node.states.data.SendData.received(SendData.java:27
\0)
at freenet.node.StateChain.received(StateChain.java:177)
at freenet.node.StateChain.received(StateChain.java:61)
at freenet.node.StateChainManagingMessageHandler$ChainContaine
\r.run(StateChainManagingMessageHandler.java:335)
at freenet.node.StateChainManagingMessageHandler$ChainContaine
\r.received(StateChainManagingMessageHandler.java:288)
at freenet.node.StateChainManagingMessageHandler$ChainContaine
\r.access$100(StateChainManagingMessageHandler.java:207)
at freenet.node.StateChainManagingMessageHandler.handle(StateC
\hainManagingMessageHandler.java:99)
at freenet.Ticker$Event.run(Ticker.java:325)
at freenet.thread.YThreadFactory$YThread.run(YThreadFactory.ja
\va:285)
java.io.IOException: Attempt to use a released TempFileBucket: /root/f
\reenet/store/temp/tbf_11b51af
at freenet.support.SpyOutputStream.checkValid(SpyOutputStream.
\java:29)
at freenet.support.SpyOutputStream.(SpyOutputStream.java
\:48)
at freenet.support.TempFileBucket.getOutputStream(TempFileBuck
\et.java:133)
at freenet.client.SegmentOutputStream.nextBucket(SegmentOutput
\Stream.java:280)
at freenet.client.SegmentOutputStream.write(SegmentOutputStrea
\m.java:192)
at java.io.OutputStream.write(OutputStream.java:58)
at freenet.crypt.DecipherOutputStream.write(DecipherOutputStre
\am.java:40)
at freenet.client.InternalClient$InternalFeedbackToken$Interna
\lDataChunkOutputStream.sendChunk(InternalClient.java:279)
at freenet.support.io.DataChunkOutputStream.write(DataChunkOut
\putStream.java:43)
at freenet.support.io.CBStripOutputStream.write(CBStripOutputS
\tream.java:41)
at freenet.OutputStreamTrailerWriter.writeTrailing(OutputStrea
\mTrailerWriter.java:19)
at freenet.node.states.data.SendData.sendWritePadding(SendData
\.java:536)
at freenet.node.states.data.SendData.received(SendData.java:27
\0)
at freenet.node.StateChain.received(StateChain.java:177)
at freenet.node.StateChain.received(StateChain.java:61)
at freenet.node.StateChainManagingMessageHandler$ChainContaine
\r.run(StateChainManagingMessageHandler.java:335)
at freenet.node.StateChainManagingMessageHandler$ChainContaine
\r.received(StateChainManagingMessageHandler.java:288)
at freenet.node.StateChainManagingMessageHandler$ChainContaine
\r.access$100(StateChainManagingMessageHandler.java:207)
at freenet.node.StateChainManagingMessageHandler.handle(StateC
\hainManagingMessageHandler.java:99)
at freenet.Ticker$Event.run(Ticker.java:325)
at freenet.thread.YThreadFactory$YThread.run(YThreadFactory.ja
\va:285)
port.SpyOutputStream.checkValid(SpyOutputStream.java:29)
at freenet.support.SpyOutputStream.(SpyOutputStream.java
\:48)
at freenet.support.TempFileBucket.getOutputStream(TempFileBuck
\et.java:133)
at freenet.client.SegmentOutputStream.nextBucket(SegmentOutput
\Stream.java:280)
at freenet.client.SegmentOutputStream.write(SegmentOutputStrea
\m.java:192)
at java.io.OutputStream.write(OutputStream.java:58)
at freenet.crypt.DecipherOutputStream.write(DecipherOutputStre
\am.java:40)
at freenet.c
[freenet-support] Re: Freenet daemon dies
Bob writes: > Presumably Java is crashing for some reason, you probably have a load of > hs_err_pid_ files in the freenet directory containing random stack > dumps. > What does `java -version` say? You should use Sun (preferably) or > Blackdown at least v1.4.2 (later versions are generally speaking > "better" but use more memory.) > > How long does it take it to die? How big is your datastore? Did it use > to work or has it always done this? > > AFAIK, the most common reason for random crashes other than hardware > issues is running out of heap with large datastores. Java stupidly > provides no real way for apps to tell they're running out of memory (or > disk space!), so starvation results in slowing to a crawl followed by an > OOM exception. Some versions of Java appear to be worse at this than > others, e.g. on blackdown 1.4.1 (only one I can use, Sparc box) I had to > set the maximum heap to 1GB yes one Gigabyte for it to start > successfully, and it doesn't even have a large store :) > Although that box is temporarily out of commission with RAM ECC errors > on one module now so that may have had something to do with it ... > > Anyway find the "java -Xmx128m etc etc" line at the end of > start-freenet.sh that actually runs freenet, and try changing the Xmx > (maximum heap size) to something larger e.g. -Xmx256m. Hopefully this > will help. > > Incidentally it's intended to get the current alpha development version, > the pretty much rewritten and significantly different (UDP, mixed > scalable darknet/lightnet etc) 0.7, to work with with Free JVMs like > Kaffe at some point which may help with this sort of issue. > > Bob No luck. I fiddled with the -Xmx option; I even downgraded to jre 1.4.2 blackdown - but it still randomly crashes without explanation. I didn't any hs_err_pid_ files, either. If you want to see any of my logs, just tell me where they are, and I'll share them. I've noticed something else strange. Before fred crashes, my hard drive goes insanely busy. The terminal responds really slowly, and the freenet web interface takes forever to load. Then, after a few minutes, silence, and no java running at all. I'm running entropy/rsa and it's been working since the day I installed it. Why does freenet have to be so much harder? thanks for your reply, Harrison
[freenet-support] Re: Freenet daemon dies
Bob <[EMAIL PROTECTED]> writes: > Presumably Java is crashing for some reason, you probably have a load of > hs_err_pid_ files in the freenet directory containing random stack > dumps. > What does `java -version` say? You should use Sun (preferably) or > Blackdown at least v1.4.2 (later versions are generally speaking > "better" but use more memory.) > > How long does it take it to die? How big is your datastore? Did it use > to work or has it always done this? > > AFAIK, the most common reason for random crashes other than hardware > issues is running out of heap with large datastores. Java stupidly > provides no real way for apps to tell they're running out of memory (or > disk space!), so starvation results in slowing to a crawl followed by an > OOM exception. Some versions of Java appear to be worse at this than > others, e.g. on blackdown 1.4.1 (only one I can use, Sparc box) I had to > set the maximum heap to 1GB yes one Gigabyte for it to start > successfully, and it doesn't even have a large store :) > Although that box is temporarily out of commission with RAM ECC errors > on one module now so that may have had something to do with it ... > > Anyway find the "java -Xmx128m etc etc" line at the end of > start-freenet.sh that actually runs freenet, and try changing the Xmx > (maximum heap size) to something larger e.g. -Xmx256m. Hopefully this > will help. > > Incidentally it's intended to get the current alpha development version, > the pretty much rewritten and significantly different (UDP, mixed > scalable darknet/lightnet etc) 0.7, to work with with Free JVMs like > Kaffe at some point which may help with this sort of issue. > > Bob No luck. I fiddled with the -Xmx option; I even downgraded to jre 1.4.2 blackdown - but it still randomly crashes without explanation. I didn't any hs_err_pid_ files, either. If you want to see any of my logs, just tell me where they are, and I'll share them. I've noticed something else strange. Before fred crashes, my hard drive goes insanely busy. The terminal responds really slowly, and the freenet web interface takes forever to load. Then, after a few minutes, silence, and no java running at all. I'm running entropy/rsa and it's been working since the day I installed it. Why does freenet have to be so much harder? thanks for your reply, Harrison ___ 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:[EMAIL PROTECTED]
[freenet-support] Re: Freenet daemon dies
> > I'm pretty stumped on this one. I installed java and freenet on my debian > machine, and when I `sh start-freenet.sh', everything works fine for a > while, but if I leave the server alone, I come back and freenet is just > not running. Neither syslog nor freenet.log indicate anything, and I don't > know where jre logs. > > - Harrison [harrisonts(a)illx.org] > Presumably Java is crashing for some reason, you probably have a load of hs_err_pid_ files in the freenet directory containing random stack dumps. What does `java -version` say? You should use Sun (preferably) or Blackdown at least v1.4.2 (later versions are generally speaking "better" but use more memory.) How long does it take it to die? How big is your datastore? Did it use to work or has it always done this? AFAIK, the most common reason for random crashes other than hardware issues is running out of heap with large datastores. Java stupidly provides no real way for apps to tell they're running out of memory (or disk space!), so starvation results in slowing to a crawl followed by an OOM exception. Some versions of Java appear to be worse at this than others, e.g. on blackdown 1.4.1 (only one I can use, Sparc box) I had to set the maximum heap to 1GB yes one Gigabyte for it to start successfully, and it doesn't even have a large store :) Although that box is temporarily out of commission with RAM ECC errors on one module now so that may have had something to do with it ... Anyway find the "java -Xmx128m etc etc" line at the end of start-freenet.sh that actually runs freenet, and try changing the Xmx (maximum heap size) to something larger e.g. -Xmx256m. Hopefully this will help. Incidentally it's intended to get the current alpha development version, the pretty much rewritten and significantly different (UDP, mixed scalable darknet/lightnet etc) 0.7, to work with with Free JVMs like Kaffe at some point which may help with this sort of issue. Bob
[freenet-support] Re: Freenet daemon dies
> > I'm pretty stumped on this one. I installed java and freenet on my debian > machine, and when I `sh start-freenet.sh', everything works fine for a > while, but if I leave the server alone, I come back and freenet is just > not running. Neither syslog nor freenet.log indicate anything, and I don't > know where jre logs. > > - Harrison [harrisonts(a)illx.org] > Presumably Java is crashing for some reason, you probably have a load of hs_err_pid_ files in the freenet directory containing random stack dumps. What does `java -version` say? You should use Sun (preferably) or Blackdown at least v1.4.2 (later versions are generally speaking "better" but use more memory.) How long does it take it to die? How big is your datastore? Did it use to work or has it always done this? AFAIK, the most common reason for random crashes other than hardware issues is running out of heap with large datastores. Java stupidly provides no real way for apps to tell they're running out of memory (or disk space!), so starvation results in slowing to a crawl followed by an OOM exception. Some versions of Java appear to be worse at this than others, e.g. on blackdown 1.4.1 (only one I can use, Sparc box) I had to set the maximum heap to 1GB yes one Gigabyte for it to start successfully, and it doesn't even have a large store :) Although that box is temporarily out of commission with RAM ECC errors on one module now so that may have had something to do with it ... Anyway find the "java -Xmx128m etc etc" line at the end of start-freenet.sh that actually runs freenet, and try changing the Xmx (maximum heap size) to something larger e.g. -Xmx256m. Hopefully this will help. Incidentally it's intended to get the current alpha development version, the pretty much rewritten and significantly different (UDP, mixed scalable darknet/lightnet etc) 0.7, to work with with Free JVMs like Kaffe at some point which may help with this sort of issue. Bob ___ 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:[EMAIL PROTECTED]
