If the directory/file paths specified in this guide do not exist in your WSO2 product, see Directory Structure of WSO2 Products to locate the paths applicable to your product.
Installing as a Linux Service - Administration Guide 4.4.x - WSO2 Documentation
Skip to end of metadata
Go to start of metadata

Follow the sections below to run a WSO2 product as a Linux service:


  • System requirements


    • ~ 2 GB minimum
    • ~ 512 MB heap size. This is generally sufficient to process typical SOAP messages but the requirements vary with larger message sizes and the number of messages processed concurrently.


    • ~ 500 MB, excluding space allocated for log files and databases.
  • Environment compatibility

    Operating Systems / Databases

    • All WSO2 Carbon-based products are Java applications that can be run on any platform that is Oracle JDK 7/8 compliant.    
    • All WSO2 Carbon-based products are generally compatible with most common DBMSs. For more information, see Working with Databases.
    • It is not recommended to use Apache DS in a production environment due to issues with scalability. Instead, it is recommended to use an LDAP like OpenLDAP for user management.
    • If you have difficulty in setting up any WSO2 product in a specific platform or database, please contact us.
  • Required applications
    The following applications are required for running the product and its samples or for building from the source code. Mandatory installations are marked with an asterisk *.




    Download Links

    Oracle Java SE Development Kit (JDK)*

    JDK 7 or 8.

    Oracle and IBM JRE 1.7 are also supported when running (not building) WSO2 products.


Setting up CARBON_HOME

Extract the WSO2 product to a preferred directory in your machine and set the environment variable CARBON_HOME to the extracted directory location.

Running the product as a Linux service

  1. To run the product as a service, create a startup script and add it to the boot sequence. The basic structure of the startup script has three parts (i.e., start, stop and restart) as follows:

    case “$1″ in
       echo “Starting the Service”
       echo “Stopping the Service”
       echo “Restarting the Service”
       echo $”Usage: $0 {start|stop|restart}”
    exit 1

    Given below is a sample startup script. <PRODUCT_HOME> can vary depending on the WSO2 product's directory.

    #! /bin/sh
    export JAVA_HOME="/usr/lib/jvm/jdk1.7.0_07"
    startcmd='<PRODUCT_HOME>/bin/wso2server.sh start > /dev/null &'
    restartcmd='<PRODUCT_HOME>/bin/wso2server.sh restart > /dev/null &'
    stopcmd='<PRODUCT_HOME>/bin/wso2server.sh stop > /dev/null &'
    case "$1" in
       echo "Starting the WSO2 Server ..."
       su -c "${startcmd}" user1
       echo "Re-starting the WSO2 Server ..."
       su -c "${restartcmd}" user1
       echo "Stopping the WSO2 Server ..."
       su -c "${stopcmd}" user1
       echo "Usage: $0 {start|stop|restart}"
    exit 1

    In the above script, the server is started as a user by the name user1 rather than the root user. For example, su -c "${startcmd}" user1 

  2. Add the script to /etc/init.d/ directory.

    If you want to keep the scripts in a location other than /etc/init.d/ folder, you can add a symbolic link to the script in /etc/init.d/ and keep the actual script in a separate location. Say your script name is prodserver and it is in /opt/WSO2/ folder, then the commands for adding a link to /etc/init.d/ is as follows:

    • Make executable: sudo chmod a+x /opt/WSO2/prodserver

    • Add a link to /etc/init.d/: sudo ln -snf /opt/WSO2/prodserver /etc/init.d/prodserver
  3. Install the startup script to respective runlevels using the command update-rc.d. For example, give the following command for the sample script shown in step1:

    sudo update-rc.d prodserver defaults 

    The defaults option in the above command makes the service to start in runlevels 2,3,4 and 5 and to stop in runlevels 0,1 and 6.

    runlevel is a mode of operation in Linux (or any Unix-style operating system). There are several runlevels in a Linux server and each of these runlevels is represented by a single digit integer. Each runlevel designates a different system configuration and allows access to a different combination of processes. 

  4. You can now start, stop and restart the server using service <service name> {start|stop|restart} command. You will be prompted for the password of the user (or root) who was used to start the service.   
  • No labels