0

Some times I have a program (EiskaltDC++) running at 100% of CPU. When I click, for example in some button of its interface, the Raspbian suddenly kill its process.

I believe that could be something related to the program does not respond and the Raspbian kill it in order to avoid the system to crash. But I'm not sure.

Anyway can I avoid this behavior? Is that possible to set any config to Raspbian understand that a process is occupied? Or this is not a behavior of the Raspbian at all?

Than you all.

  • Please clarify what program is suddenly hogging the CPU. "Raspbian suddenly kill its process" -> Not unless it has also consumed all the RAM. So either that's happening (in which case this is probably not a program you want to be using), or else it is a bug in the program itself. – goldilocks Feb 25 '18 at 14:43
  • @goldilocks I did some clarifications... – Helder Feb 26 '18 at 11:21
1

Some times I have a program (EiskaltDC++) running at 100% of CPU.

This seems odd considering it looks more or less like file sharing software -- unless of course it is interacting with hundreds or thousands of other nodes at once. I guess it is up to you to decide whether that is appropriate.

the Raspbian kill it in order to avoid the system to crash

No, a process running a CPU up to 100% is fine, at least in terms of operating system tolerances. Of course, if this is on a single core machine, the user interface is going to become sluggish or unusable, but there is nothing the OS can do about that (except kill the process, but again it absolutely will not do that).

To the extent that there are critical kernel threads that need to run that aren't servicing the greedy process directly, these have scheduling priority, so they will get to run. However, what they need to do is not processor intensive so you will not notice this impact the usage of the greedy process.

Keep in mind that user processes cannot really cause a system crash (running the system out of memory is one sort of exception I'll get to), at least not by accident, and as long as they are not run with root privilleges. A privileged process that can crash the system in some sense (e.g., by killing off other processes or overwriting critical libraries and application code on disk) will simply be allowed to do so. An unprivileged process won't have permission to do any of that, so there is no need to kill it.

There are two scenarios in which the OS will kill a process:

  1. Memory access violation, aka. segmentation fault. This is when a process attempts to write to memory that has not been allocated to it. Once upon a time (think 1970s or early 80s), this was a real potential threat to other processes and the system, but processes on a modern operating system run in a virtual address space whereby addresses outside of that simply refer to space that does not exist. Which is why, when they attempt to access it, they are trying to do something impossible, and the OS will kill it.

  2. The system has run out of physical memory. On linux, if you occupy 100% of RAM, as soon as something wants more the kernel invokes the "OOM killer". This selects a process to kill to free up memory. Generally this will be something that has been allocated a lot, or has recently been asking for more and more.

It seems to me that #2 is unlikely if the trigger is you clicking a button. In any case, it is easy to verify if you check memory use (e.g., with free).

Anyway can I avoid this behavior?

For #1 (seg fault), no, not unless you can fix the program. There is no logical reason for a program to try and access non-existent memory and anyone who programs in a language which would permit this (many of them don't) tries their best to avoid doing so. If they fail, then this constitutes a bug in the program, which is what your problem actually sounds like. Such bugs can always be fixed, but this does not mean they all have been.

To make sure that last point is clear, although technically it is the OS that kills the process, this is a bit like shooting yourself in the head and saying technically I did not kill myself, the gun did. There is nothing else that can happen.

With regard to the out-of-memory issue, you should first identify this is actually the problem. If, before you hit the button, free shows almost no memory available, then after the system crashes, run sudo journalctl -n 500 | grep -i "oom.killer". If it says anything, then this would confirm what is happening.

If that is the case, again there's not much that can be done if there is some bug in this program that keeps gobbling memory, or if it simply needs more than the Pi can provide.

  • thank you for your explanation. It seems the software has some issues... – Helder Feb 26 '18 at 15:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.