Grace period for pod deletion set to 0 doesn't allow for graceful termination of apps

[mmallonqcif]

containerproxy/src/main/java/eu/openanalytics/containerproxy/backend/kubernetes/KubernetesBackend.java

Line 729 in b3bdf4e

// specify gracePeriod 0, this was the default in previous version of the fabric8 k8s client

Is it possible to make the grace period for deleting a pod configurable? As this currently stands, a pod is sent a kill -s SIGKILL immediately after a user presses the stop app button. Ideally, this would be customisable so that a container can instead get a kill -s SIGTERM and trap that to perform resource cleanup. The example I've hit is running rstudio server in ShinyProxy needs time to send a SIGUSR1 to gracefully clean up a running rsession. As things stand, if you have persistent storage under the rstudio user home directory, on restarting the app, a user is presented with an error message stating the previous session was abnormally terminated due to an unexpected crash.

[LEDfan]

Hi, thanks for opening this issue!

I agree that it would be useful to be able to configure this, exactly for the use-case you described. I created an internal ticket for this, and normally it should be included in the next (feature) release.

As things stand, if you have persistent storage under the rstudio user home directory, on restarting the app, a user is presented with an error message stating the previous session was abnormally terminated due to an unexpected crash.

We have similar setups, where we run RStudio in ShinyProxy. We did notice, that if users are allowed to launch multiple instances of ShinyProxy, and these use the same directory to store the RStudio state, the state might become corrupt (even with the grace period workaround).
Maybe you are not allowing multiple instances, but otherwise it might make sense to verify whether changing the grace period solves your issue.
In our setup, we eventually solved this by mounting an emptyDir volume in the config directory of rstudio.

[mmallonqcif]

Thanks!

That is an excellent point on the multiple instances aspect. We do intend there to be only one instance per user but we'll also want to deploy different versions as separate shiny apps so in principle, a user could launch multiple of them that way. However, our PVC currently is set to RWO which blocks multiple pods at that level in a somewhat user unfriendly way. That's something we'll look at changing to RWX in the future (need some work with our infrastructure providers to do that well), so I'll look at setting RSTUDIO_CONFIG_HOME on a per version basis. Again, thanks for the extra details, that's been very helpful.