4 ms·

> allows resource requests or denies them and (hopefully) kills the application Why is killing the application desirable behaviour over just denying the reques

> allows resource requests or denies them and (hopefully) kills the application Why is killing the application desirable behaviour over just denying the request?

pas 10y ago
Helps debugging. Though a sysfs/procfs config for this would go a long way.
shanemhansen 10y ago
There's a school of thought in security that believes you should hard fail at any attempt to violate an invariant. I believe the linux grsec patches do this. They will just crash the kernel if they see something at runtime that they don't like.
- aaronmdjones 10y ago
  Indeed; if you have the Active Kernel Exploit Response feature enabled in grsec, and a root process triggers a kernel OOPS, it will panic() the kernel. You can combine this with the panic= kernel command-line argument to set a reboot delay, but for headed (rather than headless) boxes it may be more desirable to keep the panic message up to see what process triggered it.
forgottenpass 10y ago
If you detect something that can not (well, should not) ever happen, it means that state of the process is no longer within designed bounds. The process' output can not be trusted, so it should stop processing. Detecting something you never expect to happen is almost tautologically stating the software doesn't know how to recover state. This, of course, relies on an architecture where another process will take care of making sure an error is bubbled to the place it needs to go, pulling failsafe, etc... I will grant some environments and/or designs make this easier than others (eg. Erlang's error handling is all about letting processes die).
dom0 10y ago
Because everyone in dev and ops ignores warnings. Only stuff that crashes is investigated.
skrebbel 10y ago
The author writes from the perspective of writing a CGI-based web app. Here, every request becomes a new OS process, so killing the application is killing the request.
Sanddancer 10y ago
If an application is making a request it hasn't marked as being one it is going to make, then chances are, there is a big problem that needs dealt with. In such a situation, crashing as soon as possible means that there's a better chance that all of the relevant data is there to pore through. If you just deny the call, then it could be many hundred of functions later, possibly with relevant data being freed up, and your job of picking through your program's entrails becomes all the more difficult.

> allows resource requests or denies them and (hopefully) kills the application Why is killing the application desirable behaviour over just denying the request?

pas 10y ago

Helps debugging. Though a sysfs/procfs config for this would go a long way.

shanemhansen 10y ago

There's a school of thought in security that believes you should hard fail at any attempt to violate an invariant. I believe the linux grsec patches do this. They will just crash the kernel if they see something at runtime that they don't like.

aaronmdjones 10y ago
Indeed; if you have the Active Kernel Exploit Response feature enabled in grsec, and a root process triggers a kernel OOPS, it will panic() the kernel. You can combine this with the panic= kernel command-line argument to set a reboot delay, but for headed (rather than headless) boxes it may be more desirable to keep the panic message up to see what process triggered it.

forgottenpass 10y ago

If you detect something that can not (well, should not) ever happen, it means that state of the process is no longer within designed bounds. The process' output can not be trusted, so it should stop processing. Detecting something you never expect to happen is almost tautologically stating the software doesn't know how to recover state. This, of course, relies on an architecture where another process will take care of making sure an error is bubbled to the place it needs to go, pulling failsafe, etc... I will grant some environments and/or designs make this easier than others (eg. Erlang's error handling is all about letting processes die).

dom0 10y ago

Because everyone in dev and ops ignores warnings. Only stuff that crashes is investigated.

skrebbel 10y ago

The author writes from the perspective of writing a CGI-based web app. Here, every request becomes a new OS process, so killing the application is killing the request.

Sanddancer 10y ago

If an application is making a request it hasn't marked as being one it is going to make, then chances are, there is a big problem that needs dealt with. In such a situation, crashing as soon as possible means that there's a better chance that all of the relevant data is there to pore through. If you just deny the call, then it could be many hundred of functions later, possibly with relevant data being freed up, and your job of picking through your program's entrails becomes all the more difficult.