You can start and stop Jedox on Linux with the script jedox-suite.sh, located directly in the installation directory. This script is called with certain parameters:
- a command that specifies what the user wants to do (
start,restart, orstop) - options that modify implicit behavior of the script itself (
--umount, and--no-umount) - One or more targets that specify which components are to be started (any combination of
olap,httpd,core, andtomcat)
The command argument is required; the others are optional. When started with only a command, the script applies this command to all Jedox components.
| Example script | Action |
./jedox-suite.sh start
|
Starts all components of Jedox by default. |
./jedox-suite.sh stop core httpd
|
Stops the core and httpd components of Jedox Web. |
./jedox-suite.sh restart olap
|
Restarts the In-Memory DB (OLAP) component but not its dependent components (Tomcat). |
Note: as of Jedox 2019.2, all services can be controlled independently, rendering the option --no-deps obsolete. That option has been deprecated. To restart OLAP without dependencies, use the script jedox-suite.sh restart olap.
Once running, the processes can be controlled by the script via their Process ID, not via the process name. Process IDs are saved as files in ../var/run and ../tomcat respectively.
Be aware that the jedox-suite.sh script and the /tomcat/jedox_tomcat.sh script now both contain an INSTALL_PATH variable with the location of your Jedox jail. This makes it possible to create symlinks to those scripts and call them from wherever you want. Combined with the Debian-, CentOS-, and SuSE-compatible init.d comment headers that are contained in these files, it is now possible to integrate the jedox-suite.sh into the system’s startup and shutdown process.
The jedox-suite.sh script automatically tries to bind-mount /dev, /proc, and /sys into the jail to make tools like netstat (used for In-Memory DB startup) work in the chroot environment. These mounts are automatically unmounted when ./jedox-suite.sh stop (without any further parameters) is issued.
You can enforce unmounting these directories using the --umount option and forbid unmounting using -no-umount.
Startup and shutdown of Jedox In-Memory DB
Starting the In-Memory DB involves launching the process and waiting for it to completely start up and listen on a configured port. Do not simply assume it is up after waiting a couple of seconds.
The same applies to the process shutdown: the script waits for the shutdown to complete, even if this means waiting for an hour or longer. This default behavior can be changed by editing /etc/rc.d/init.d/jedox_olap and changing the variables OLAP_START_TIMEOUT and OLAP_STOP_TIMEOUT.
Timeouts may also be configured for the Jedox core process in /etc/rc.d/init.d/jedox_core and the Jedox Tomcat process in /tomcat-rpc/jedox_tomcat.sh.
Timeout for SSS
When stopping Jedox Suite or SSS service on Linux, SSS service can get stuck on shutdown. When this happens, the SSS service needs to be killed manually so that shutdown script can go on and stop other services. An alternative solution is to set a timeout period.
To set a timeout period, In the file /etc/rc.d/init.d/jedox_core, the admin can change the value of the variable WEB_CORE_STOP_TIMEOUT. This variable is defined as the number of seconds the shutdown script will wait to stop the SSS service (if the number is greater than zero). If the SSS service did not stop in the stated time, SSS process will be killed by the shutdown script. In that case, the admin does not need to do anything. If WEB_CORE_STOP_TIMEOUT is zero, then the SSS process will not be killed by the shutdown script.
In Jedox 2018.3 and earlier, the variable WEB_CORE_STOP_TIMEOUT was set to zero (meaning no timeout). As of Jedox 2018.4, the default value is 300, which means that the shutdown script will wait five minutes before it kills the SSS process.
Updated June 5, 2023