<p><code>kill -9</code> is used by the kernel to terminate stateful programs that are no longer responding (including to shutdown requests). To gracefully shut down a stateful app you would use <code>kill -15</code> which instructs the application to call it's shutdown functions and do the requisite cleanup. If you app is truly stateless, there should be no difference in the results of <code>kill -9</code> and <code>kill -15</code>, but technically, a graceful shutdown of this program would still be <code>kill -15</code></p>

CC BY-SA 3.0
2017-09-15T23:27:18.103Z
Actually there will be difference, even in stateless app. `SIGKILL` is uncatchable which mean that app will halt in place, while with `SIGTERM` you can handle it gracefully like finishing all existing requests (but not accepting new one) while `SIGKILL` do not give you such opportunity.
Hauleth
CC BY-SA 3.0
2017-09-16T00:39:23.263Z
I woudn't really define that as a "Stateless" app then...
James Shewey
CC BY-SA 3.0
2017-09-16T07:20:19.603Z
Having an open connection can hardly be called "state" in this context - if it were, there could be by definition no stateless app at all (i.e., none that could serve requests).
AnoE
CC BY-SA 3.0
2017-09-16T14:31:13.397Z
The [TCP *state* diagram disagrees with you](https://upload.wikimedia.org/wikipedia/en/archive/5/57/20080306050740%21Tcp_state_diagram.png) and the cconnection is in the `ESTABLISHED` *state*. I'm sure people (even very smart people with official documentation) call these kinds of programs stateless, but I think they are probably using this terminology wrong... @AnoE - not all apps are networking apps and accept input from a TCP stack. In fact, the more I think about it, there probably are no truly stateless apps.
James Shewey
CC BY-SA 3.0
2017-09-16T14:34:23.690Z
Since these apps operate on a [*state machine*](http://blog.markshead.com/869/state-machines-computer-science/) I'm pretty sure that's the case. They all have to be in some state or another since the state machine they run on is always in some sort of state. Really, whomever is picking this concept probably just should have chosen a different term, because I'm really not sure what they hell they meant by stateless and I'm pretty sure I can come up with a corner case for every situation where death of the app results in data loss.
James Shewey
CC BY-SA 3.0
2017-09-16T18:14:42.890Z
@JamesShewey, in my comment, I use "state" in the sense of REST. To quote wikipedia, "The client–server communication is constrained by no client context being stored on the server between requests. Each request from any client contains all the information necessary to service the request, and session state is held in the client". When talking about "cloud", "data" and "app", that seems to make perfect sense to me. Obviously, if you consider parts like TCP/IP or even the RAM or process table of your server as "state", then there's no point to talk about "stateless" at all.
AnoE
CC BY-SA 3.0
2017-09-20T16:51:52.060Z
JamesShewey by your definition no computer program can be called stateless as any application need at least 1 place that store current state - instruction pointer. @AnoE is correct, in context of web development state mean any dada store between requests about app (DB, files, any shared context) not TCP connection state.
Hauleth
CC BY-SA 3.0
2017-09-15T20:21:47.833Z
2017-09-15T20:21:47.833Z
James Shewey
<blockquote>
  <p>A stateless app can always handle kill -9?</p>
</blockquote>

<p>Yes. But even a stateless app handles connections from the outside (or it would do nothing, really!). That is the issue here. If your app, say, some HTTP server that only serves static files, and is thus stateless, were to be routinely killed with -9, then ever so often, you would kill it with an active connection. So your customer would get some HTTP error code. In the best case, it is an unimportant small image and he doesn't even notice; in the worst case, it is your main <code>.js</code> or <code>.css</code> file and he <em>will</em> indeed notice badly.</p>

<p>So, by using a weaker signal, you give your stateless app the chance to finish the current request before shutting down. </p>

<p>Obviously, you can finish it off with -9 if it does not go away after a second or two (or however long you wish to give it time to end its business).</p>

CC BY-SA 3.0
2017-09-16T09:24:54.063Z
2017-09-16T09:24:54.063Z
AnoE
<p>Quote from CF training on twelve-factor app’s processes are disposable:</p>

<blockquote>
  <p>Apps should also shut down gracefully (but can also die unexpectedly).
  Cloud Foundry stops routing traffic nearly instantaneously to failed
  or shutdown instances.</p>
</blockquote>

<p>Cloud Foundry apps are stateless. I don't understand how to shut down gracefully a stateless app. A stateless app can always handle <code>kill -9</code>?</p>

<cloud><data>
How to shut down a stateless app gracefully?
Sybil
# How to shut down a stateless app gracefully?

(Asked by: username_0 on 2017-09-15)

Quote from CF training on twelve-factor app’s processes are disposable:

> Apps should also shut down gracefully (but can also die unexpectedly).
> Cloud Foundry stops routing traffic nearly instantaneously to failed
> or shutdown instances.

Cloud Foundry apps are stateless. I don't understand how to shut down gracefully a stateless app. A stateless app can always handle `kill -9`?

**Tags:** cloud, data


---

## 2 answers

### Answer by username_3 on 2017-09-16. Score: 3 | Accepted answer

> A stateless app can always handle kill -9?

Yes. But even a stateless app handles connections from the outside (or it would do nothing, really!). That is the issue here. If your app, say, some HTTP server that only serves static files, and is thus stateless, were to be routinely killed with -9, then ever so often, you would kill it with an active connection. So your customer would get some HTTP error code. In the best case, it is an unimportant small image and he doesn't even notice; in the worst case, it is your main `.js` or `.css` file and he *will* indeed notice badly.

So, by using a weaker signal, you give your stateless app the chance to finish the current request before shutting down.

Obviously, you can finish it off with -9 if it does not go away after a second or two (or however long you wish to give it time to end its business).


---

### Answer by username_1 on 2017-09-15. Score: 6

`kill -9` is used by the kernel to terminate stateful programs that are no longer responding (including to shutdown requests). To gracefully shut down a stateful app you would use `kill -15` which instructs the application to call it's shutdown functions and do the requisite cleanup. If you app is truly stateless, there should be no difference in the results of `kill -9` and `kill -15`, but technically, a graceful shutdown of this program would still be `kill -15`

> **Comments:**
> **username_2**: Actually there will be difference, even in stateless app. `SIGKILL` is uncatchable which mean that app will halt in place, while with `SIGTERM` you can handle it gracefully like finishing all existing requests (but not accepting new one) while `SIGKILL` do not give you such opportunity.  
> **username_1**: I woudn't really define that as a "Stateless" app then...  
> **username_3**: Having an open connection can hardly be called "state" in this context - if it were, there could be by definition no stateless app at all (i.e., none that could serve requests).  
> **username_1**: The [TCP *state* diagram disagrees with you](https://upload.wikimedia.org/wikipedia/en/archive/5/57/20080306050740%21Tcp_state_diagram.png) and the cconnection is in the `ESTABLISHED` *state*. I'm sure people (even very smart people with official documentation) call these kinds of programs stateless, but I think they are probably using this terminology wrong... @username_3 - not all apps are networking apps and accept input from a TCP stack. In fact, the more I think about it, there probably are no truly stateless apps.  
> **username_1**: Since these apps operate on a [*state machine*](http://blog.markshead.com/869/state-machines-computer-science/) I'm pretty sure that's the case. They all have to be in some state or another since the state machine they run on is always in some sort of state. Really, whomever is picking this concept probably just should have chosen a different term, because I'm really not sure what they hell they meant by stateless and I'm pretty sure I can come up with a corner case for every situation where death of the app results in data loss.  
> **username_3**: @JamesShewey, in my comment, I use "state" in the sense of REST. To quote wikipedia, "The client–server communication is constrained by no client context being stored on the server between requests. Each request from any client contains all the information necessary to service the request, and session state is held in the client". When talking about "cloud", "data" and "app", that seems to make perfect sense to me. Obviously, if you consider parts like TCP/IP or even the RAM or process table of your server as "state", then there's no point to talk about "stateless" at all.  
> **username_2**: JamesShewey by your definition no computer program can be called stateless as any application need at least 1 place that store current state - instruction pointer. @username_3 is correct, in context of web development state mean any dada store between requests about app (DB, files, any shared context) not TCP connection state.  

---

