@godaddy/terminus - npm Package Compare versions

Comparing version 4.10.2 to 4.11.0

lib/terminus.js

@@ -129,3 +129,3 @@ 'use strict'
 function decorateWithSignalHandler (server, state, options) {
-  const { signals, onSignal, beforeShutdown, onShutdown, timeout, logger } = options
+  const { signals, useExit0, onSignal, beforeShutdown, onShutdown, timeout, logger } = options
 
@@ -144,4 +144,10 @@ stoppable(server, timeout)
         await onShutdown()
-        signals.forEach(sig => process.removeListener(sig, cleanup))
-        process.kill(process.pid, signal)
+        if (useExit0) {
+          // Exit process
+          process.exit(0)
+        } else {
+          // Resend recieved signal but remove traps beforehand
+          signals.forEach(sig => process.removeListener(sig, cleanup))
+          process.kill(process.pid, signal)
+        }
       } catch (error) {
@@ -173,2 +179,3 @@ logger('error happened during shutdown', error)
     signals = [],
+    useExit0 = false,
     timeout = 1000,
@@ -207,2 +214,3 @@ healthChecks = {},
     signals,
+    useExit0,
     onSignal,
@@ -209,0 +217,0 @@ beforeShutdown,

package.json

 {
   "name": "@godaddy/terminus",
-  "version": "4.10.2",
+  "version": "4.11.0",
   "description": "",
@@ -5,0 +5,0 @@ "main": "index.js",

README.md

@@ -67,2 +67,3 @@ # terminus
   signals,                          // [optional = []] array of signals to listen for relative to shutdown
+  useExit0,                         // [optional = false] instead of sending the received signal again without beeing catched, the process will exit(0)
   sendFailuresDuringShutdown,       // [optional = true] whether or not to send failure (503) during shutdown
@@ -187,3 +188,4 @@ beforeShutdown,                   // [optional] called before the HTTP server starts its shutdown
 
-During that time window (30 seconds by default), the Pod is in the `terminating` state and will be removed from any Services by a controller. The Pod itself needs to catch the `SIGTERM` signal and start failing any readiness probes.
+During that time window (30 seconds by default), the Pod is in the `terminating` state and will be removed from any Services by a controller.
+The Pod itself needs to catch the `SIGTERM` signal and start failing any readiness probes.
 
@@ -194,4 +196,8 @@ > If the ingress controller you use route via the Service, it is not an issue for your case. At the time of this writing, we use the nginx ingress controller which routes traffic directly to the Pods.
 
-To make sure you don't lose any connections, we recommend delaying the shutdown with the number of milliseconds that's defined by the readiness probe in your deployment configuration. To help with this, terminus exposes an option called `beforeShutdown` that takes any Promise-returning function.
+To make sure you don't lose any connections, we recommend delaying the shutdown with the number of milliseconds that's defined by the readiness probe in your deployment configuration.
+To help with this, terminus exposes an option called `beforeShutdown` that takes any Promise-returning function.
 
+Also it makes sense to use the `useExit0 = true` option to signal Kubernetes that the container exited gracefully.
+Otherwise APM's will send you alerts, in some cases.
+
 ```javascript
@@ -207,3 +213,4 @@ function beforeShutdown () {
 createTerminus(server, {
-  beforeShutdown
+  beforeShutdown,
+  useExit0: true
 })
@@ -210,0 +217,0 @@ ```

New alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Fixed alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

29125

increased by3.02%

Number of package files

28

increased by7.69%

Lines of code

572

increased by3.25%

Number of lines in readme file

224

increased by3.23%

Worsened metrics

Number of medium supply chain risk alerts

15

increased by7.14%

No dependency changes