Wakanda Server scripted clean shutdown

Question

What is best practice to perform a clean shutdown of a Wakanda server via OS X shell scripting?

This would be with a solution currently loaded and operating.

Answer 1

When running Wakanda Server as a background process, you can cleanly stop it using the process ID and the kill -sigterm command.

SIGTERM

The SIGTERM signal is sent to a process to request its termination. Unlike the SIGKILL signal, it can be caught and interpreted or ignored by the process. This allows the process to perform nice termination releasing resources and saving state if appropriate. SIGINT is nearly identical to SIGTERM.

Here is some sample code that demonstrates this:

ps -A | grep wakanda-server   
kill -SIGTERM pid_from_line_above

Note: you must replace pid_from_line_above with the PID that is returned by ps -A | grep wakanda-server

---

For your bash script, maybe something like this would work:

killall -TERM /Applications/Wakanda\ Server.app/Contents/MacOS/Wakanda\ Server
sleep 15
killall -KILL /Applications/Wakanda\ Server.app/Contents/MacOS/Wakanda\ Server

The script first sends the normal termination signal to the process, then waits 15 seconds before sending the kill signal to the process forcing it to quit.

Reminder: kill -SIGKILL PID cannot be caught or ignored.

SIGKILL

The SIGKILL signal is sent to a process to cause it to terminate immediately (kill). In contrast to SIGTERM and SIGINT, this signal cannot be caught or ignored, and the receiving process cannot perform any clean-up upon receiving this signal.

---

Although a better way of doing this may be to use a LaunchDaemon as suggested in response to osx startupitems shell script does not launch application

See also: Administrating Wakanda Server for Unix

Answer 2

This shell script is tested working in Mac OS:

#killWakanda.sh
pids=$(pgrep $1) 
kill -9 $pids

Depends on you are running Wakanda community version of Enterprise version. The name of Wakanda server could be passed in as a parameter (Wakanda Server or Wakanda Enterprise Server):

This kills Wakanda Enterprise Server

sh /pathOfShellScript/killWakanda.sh Wakanda Enterprise Server

This kills Wakanda Community Server

sh /pathOfShellScript/killWakanda.sh Wakanda Server

Answer 3

With all the suggestions for using kill -9, please be aware that kill -9 does not shut down the Wakanda server in a gently manner.

We use it for several years now and shutting the server down this way still causes data corruption in some cases. Especially when you have shared workers working with the database in the background. Wakanda does not cleanly stop the workers.

Our current solution to minimize the problem is: 1. Sent a REST-request to Wakanda to stop the workers (you have to write your own server side method for this). This will still won't shutdown the processes in all cases! 2. Trying to kill the server without -9 parameter (up to three times) 3. If the Wakanda server is still alive, use kill -9

Btw. we asked for this a long time ago. Some reliable commandline tool like: rcwakanda start/stop/restart similar to other services like apache would be helpful.

Answer 4

I've had the same experience as Michael Hong. I would not use kill -9 to shut down a Wakanda server. It does not gracefully shut down workers and can lead to data corruption. The correct way to shut down a Wakanda server is using the solution.quitServer() function as documented here: http://doc.wakanda.org/home2.en.html#/Global-Application/Solution/quitServer.301-635546.en.html

My solution has been to have one shared worker that manages all other workers (a "worker manager"). An RPC/REST call can be made to call the "worker manager" to quit the server. The worker manager then calls all the other workers to give them time to gracefully close. Then after X seconds the worker manager calls solution.quitServer().

Answer 5

The best practice for the upcoming release 1.1.0 :

• Handle the applicationWillStop event on a service to handle app specific closing logic
• service wakanda stop for Ubuntu and a normal kill for Mac OS ( kill -9 should always be the last resort after some kind of timeout but this should not be necessary anymore)

The best practice for the current release 1.0.x :

• Prepare server stop by using an HTTP Request Handler or another method (make sure to secure this very well and accept connections only from localhost)
• service wakanda stop for Ubuntu and a normal kill for Mac OS ( kill -9 should always be the last resort after some kind of timeout but this should not be necessary anymore)

  ---

More details :

We should make a distinction between an HTTP Server like Apache and an application server like Wakanda Server.

For example, when you are using a SharedWorker in Wakanda, your are creating a separate thread that is going to run some code. Suppose that worker is doing some kind of critical data manipulation. If you let the server close that worker for you, it might cause data incoherence in your application. You should therefore handle any business logic specific "clean" close before the server stops the app.

Starting from version 1.1.0, instead of creating a special HTTP Request Handler that you can call to prepare the server's stop, you can use a service that handles the event applicationWillStop.

When the server receives a blockable kill signal ( TERM, QUIT, INT ), it will start the stopping process ( The following is true for version 1.1.x of Wakanda Digital App Factory ) :

• Notify every service of the event applicationWillStop
• Notify every service of the event httpServerWillStop
• Wait for all services code execution to be done - Services are called one at a time (the server waits for the code handling the event to end its execution before calling the next service) -
• Refuse any new incoming HTTP Requests
• Process all HTTP requests in the HTTP Server's queue
• Ask all the workers and threads executing JS code to stop the execution (including request handlers code).
• Check if there are any threads/JS Contexts still active, if it is the case wait maximum 5 seconds.
• The server forces all JavaScript contexts to stop the execution and kills all the remaining threads
• The server waits for the threads to be closed
• The server stops

In the versions prior to 1.1.0 the server asks the workers to close before notifying the services about the closing events. That is why we couldn't rely on the services to do a clean close of the SharedWorkers.