So I was reading How Linux Works by Brian Ward. In it, he says, the user-space applications going bad will not wreck the system.

Figure 1-1. General Linux system organization There is a critical difference between the ways that the kernel and user processes run: The kernel runs in kernel mode, and the user processes run in user mode. Code running in kernel mode has unrestricted access to the processor and main memory. This is a powerful but dangerous privilege that allows a kernel process to easily crash the entire system. The area that only the kernel can access is called kernel space.

User mode, in comparison, restricts access to a (usually quite small) subset of memory and safe CPU operations. User space refers to the parts of main memory that the user processes can access. If a process makes a mistake and crashes, the consequences are limited and can be cleaned up by the kernel. This means that if your web browser crashes, it probably won’t take down the scientific computation that you’ve been running in the background for days.

In theory, a user process gone haywire can’t cause serious damage to the rest of the system. In reality, it depends on what you consider “serious damage,” as well as the particular privileges of the process, because some processes are allowed to do more than others. For example, can a user process completely wreck the data on a disk? With the correct permissions, yes—and you may consider this to be fairly dangerous. There are safeguards to prevent this, however, and most processes simply aren’t allowed to wreak havoc in this manner.

I have read that a web server, for example, runs in user-space and I have seen it consuming all the memory of the system and forcing the server to be crashed. But what the author says is contradicting to this.

I don't know if I am misinterpreting what the author is trying to say. My apologies.

Can someone please explain if the userspace applications can wreck the system or not and why.

Thanks for your humble help.

  • 1
    "consuming all the memory of the system and forcing the server to be crashed" ... The system must have been swapping heavily, giving the impression of non-responsiveness. Otherwise the OOM killer would have come out of retirement and taken care of the web server.
    – muru
    Commented Jun 13, 2019 at 3:54
  • @muru The OOM killer might not have killed the webserver. Without knowing more detail about the way the web-server was divided into process, we really couldn't guess the /proc/pid/oom_score. The OOM killer isn't guaranteed to go after the troublesome program, especially where that program is composed of many smaller processes. Commented Jun 13, 2019 at 6:59
  • @PhilipCouling true, it might not, but if the webserver continues misbehaving, it will be killed eventually, once the OOM killer has run out of other targets
    – muru
    Commented Jun 13, 2019 at 7:13

1 Answer 1


I don't think you've misinterpreted anything particularly. Yes those two things you've read do appear to disagree. The topic that has not been covered by the author (Brian Ward) is Denial of Service Attacks, which despite their name aren't always malicious. Sometimes they happen by accident.

I've personally witnessed a server be taken down by a fork bomb. Sure the server was technically still running but no other service was accessible and the accidental fork bomb had an expected run time of around a trillion years. Most people would call that crashed.

Denial of Service attacks are different because they are composed of too many otherwise acceptable actions. For example you can request the home page of a website, that's acceptable. Now if we get a million computers to all request it a hundred million times, that's going to cause trouble.

Now there are some protections in the Kernal meaning that it's harder to do than you might expect. But the basic principle is that a user running many threads can use a particular (limited) resource so much that other threads (from other users) are starved, unable to use that resource.

Depending on the resource in question the Kernel can prevent this with tools like cgroups. But if you talk about a more general case where the sysadmin / software developers haven't restricted things then you will find examples such as web-servers going nuts and sucking up all available resource.

One resource to mention in particular is memory. The Kernel will start killing processes when it completely runs out of memory and swap. It's therefore possible for processes to force the kernel to kill other processes and contrary to some people's belief, this is in no way guaranteed to kill the troublesome processes.

This means that an uncontrolled user space program may do something which will ultimately force the kernel to kill off completely unrelated programs. I would call that scenario "causing havoc" even though the system is behaving correctly.

  • Thanks for the kind explanation, that gives a lot of info of what I was looking for. Is it good idea to continue with this book?
    – Vignesh SP
    Commented Jun 13, 2019 at 12:55
  • @VigneshSP I've never read it but the shot snipet you've posted looks okay. Commented Jun 13, 2019 at 12:58
  • I'll take that as "looks okay to continue ", thanks again:)
    – Vignesh SP
    Commented Jun 13, 2019 at 13:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .