5

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?

Sybil
  • 452
  • 4
  • 11

2 Answers2

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

James Shewey
  • 3,734
  • 1
  • 15
  • 38
  • 1
    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 Sep 15 '17 at 23:27
  • I woudn't really define that as a "Stateless" app then... – James Shewey Sep 16 '17 at 00:39
  • 1
    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 Sep 16 '17 at 07:20
  • The TCP state diagram disagrees with you 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 Sep 16 '17 at 14:31
  • Since these apps operate on a state machine 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 Sep 16 '17 at 14:34
  • 2
    @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 Sep 16 '17 at 18:14
  • 1
    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 Sep 20 '17 at 16:51
3

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).

AnoE
  • 4,876
  • 13
  • 25