Does anyone know what this means? I'm getting it in my ethereum console quite a bit. It doesn't seem to be breaking anything that I can tell.
In Linux it means that you are exceeding the max filesize.
The max file-size in Linux vary depending on the Kernel version (could be 2Gb).
So, it seems that you are doing an operation that is causing the OS to make a very large file.
(If you can share the full context for the error message we can give you more detailed answer.)
Related
I am trying to do an assignment (from another univ's coursepage) which has a line in the starter code (Python with mininet) as
os.system("rmmod tcp_probe; modprobe tcp_probe full=1")
Popen("cat /proc/net/tcpprobe > %s" % (outfile), shell=True)
which gives an error saying that tcp_probe has been disabled.
I found out by googling that tcp_probe has been deprecated in the linux kernel. However it just asks me to 'do the same using ftrace'. I have tried searching online but could not find out how to use ftrace to achieve the same.
Any help is appreciated.
tldr;
Unfortunately, I could not find any way to get TCP tracepoints to work in Mininet, which is what ftrace would uses. The reason for this is that the mininet's /sys/kern/debug directory is empty, i.e., tracing cannot be enabled.
Options:
1. Using mininet-tracing (not recommended)
There probably is a way to get the kernel to include this, or you could use https://github.com/mininet/mininet-tracing which might get you what you need, but I have seen reports that it is slow, and has been updated 9 years ago...
2. Writing a new kernel module (I have tested this and it works)
What I found as a solution instead, was to force printing for the TCP I had in mind and then take a look at the results that way. In order to enable this, you would essentially need to extend some of TCP's behaviour and (quite possibly) reuse the TCP module you have in mind. And create a new kernel module.
Here I have provided an example that you can use. It logs socket information on each ACK. I also included a Makefile and a script to load/unload the kernel module. After you enable the module and let some traffic flow (assuming you are on a debian-based linux) you should be able to find the logs of your TCP in /var/log/kern.log.
Note:
This is a hacky way around the issue, but was good enough for my needs, and hopefully can help someone else too.
I have an assignment to implement simple fault-tolerance in an OpenMPI application. The problem we are having is that, despite setting the MPI error handling to MPI_ERRORS_RETURN, when one of our nodes is unplugged from the cluster we get the following error on the next MPI_ call after a lengthy hang:
[btl_tcp_endpoint.c:655:mca_btl_tcp_endpoint_complete_connect] connect() failed: Connection timed out (110)
My take from this is that it is not possible to continue processing on all other nodes when one node drops from the network with OpenMPI. Can anyone confirm this for me, or point me in a direction for preventing the btl_tcp_endpoint error?
We are using OpenMPI version 1.6.5.
The MPI_ERRORS_RETURN code paths are not well tested (and probably not well implemented) in Open MPI. They simply haven't been a priority, so we've never really done much work in this area.
Sorry.
I am using java "1.6.0_24" OpenJDK. Sometimes when I run my program, all that I get is a message
Could not create the Java virtual machine.".
Some other times, the program runs perfectly fine.
Is there some set of options that I can add to get more verbose output as to the exact error (maybe even something similar to a core dump?).
This is probably not related to the heap size since in that case, it does give a definite and clear error message like :-
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
This I could fix with setting -Xms and -Xmx appropriately. However, the JVM quitting without printing anything else at all is very unhelpful.
Just to clarify, my question is about coaxing more verbose error messages or some sort of status files / core dumps which I can then use for debugging.
Start with a small heap. Set -Xms far lower than -Xmx. Increase the maximum heap size, -Xmx to some 1024(or 2048 depending on your application). Set -Xms to some 512 (I'd say half of Xmx)
Not sure about OpenJDK but have you tried http://www.oracle.com/technetwork/java/javase/crashes-137240.html#gbyyz ?
While load testing of my erlang server with increasing number(100, 200, 300,....) of clients, which also in erlang, I got a some message on windows console if the number of clients exceeds 200. The message is
*"Crash dump was written to: erl_crash.dump.
eheap_alloc: Cannot allocate 8414160 bytes of memory (of type "heap"). Abnormal termination"*.
This is the problem with windows. But if I test server load on Linux system, it can work for any number of clients until the system load reach to saturation state.
can any one help me to override this problem ?
Thank you.
Simply put, your app ran out of memory. Probably the easiest way to monitor this is to check out which process is eating up the memory. You can check up with os_mon, or easier still:
etop:start()
If I try to quit Firefox when it's "Looking up domain.com..." it beachballs (hangs), goes into "not responding" status, then finally quits. It does this without fail.
This is on Mac with the latest FF, but it's always been this way for me, even on Windows with FF and I've noticed it with other applications.
Is there any technical reason why this can't be handled better?
No. You can use threads or even seperate processes to do this asynchronously (non-blocking). This is just poorly written software.
Aside from that, I don't have this particular problem with FF...
You should check bugzilla.mozilla.org to see if there are any recent bugs regarding the DNS service. Historically, this type of problem is very rare in Firefox and other mozilla based products, but there have been times where specific problems caused the DNS service to die or wait until a timeout.
The other important question is: are you sure it is DNS? A packet trace or necko debug logs might be useful. The way the status bar works, what is says is not necessarily what is keeping it from quitting.
There is a bug report for this problem. It has been around since at least 2004.