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?

Improve this question

2 Answers 2

Reset to default
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).

Improve this answer
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

Improve this answer
7
  • 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
    Commented Sep 15, 2017 at 23:27
  • I woudn't really define that as a "Stateless" app then...
    – James Shewey
    Commented Sep 16, 2017 at 0: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
    Commented Sep 16, 2017 at 7:20
  • 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
    Commented Sep 16, 2017 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
    Commented Sep 20, 2017 at 16:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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