+

Search Tips   |   Advanced Search

Automatically restarting server processes

There are several server processes that the operating system can monitor and automatically restart when the server processes stop abnormally.

To set up this function on a Microsoft Windows operating system, we must belong to the Administrator group and have the following advanced user rights:

The Installation wizard grants you the user rights if your user ID is part of the administrator group.

(Windows) If we are running on a Microsoft Windows Operating System, the Installation wizard displays a message that states that although the advanced user rights are now effective, they do not display as effective until the next time you log on to the Windows machine.

(Windows) We can also add the advanced user rights manually if we are performing a silent installation on a Windows operating system. For example, to grant the user rights to your administrator group user ID on a Windows operating system, perform the following procedure:

  1. Click...

      Control Panel > Administrative Tools > Local Security Policy > Local Policies > User Rights Assignments > Act as part of the operating system (Right-click) > Security > Add > user ID > Add > > OK > OK > Log on as a service (right-click) > Security > Add > OK > OK

  2. Reboot the machine to make the settings effective.

There are several environments where we might use this function of automatically restarting servers. We can restart the server1 managed node process, for example. Here is a list of processes we might consider restarting:

(Windows) On a Windows operating system, we can create Windows services during installation, using the installation wizard. Each Windows service controls a single process, such as a stand-alone product instance. Multiple stand-alone Application Server processes require multiple Windows services, which we can define. The wizard lets you create services for these servers:

The installation wizard does not provide a way to create a service for a node agent because the deployment manager instantiates each node agent after installation when you add an Application Server node to the deployment manager cell. For this reason, we must manually create a function that automatically starts a failed node agent server process.

On a Linux or supported UNIX operating system, we must manually create a shell script that automatically starts any of the processes previously mentioned. Each UNIX shell script controls a single process, such as a stand-alone product instance. ultiple stand-alone Application Server processes require multiple UNIX scripts, which we can define.

In a WebSphere Application Server, Network Deployment environment, the addNode or startNode command starts a single unmonitored node agent only, the nodeagent process, and does not start all of the processes that we might define on the node. While running, the node agent monitors and restarts Application Server processes on that node, on either a Windows or a Linux and UNIX-based platform. Each Application Server process has MonitoringPolicy configuration settings that the node agent uses when monitoring and restarting the process.

HCL recommends that we manually set up a monitored process for the deployment manager dmgr server and for any node agent defined for our system. To set up a monitored process:


Tasks

  1. (Windows) Use the Profile Management tool to set up a Windows service to automatically monitor and restart processes related to the product.

    • Perform the following procedure from the Profile Management tool to select services that the installation wizard can set up:

      1. Click Run WAS ND as a service.

        If we select this option, the installation wizard creates the following service during installation:

          IBMWAS6Service - node

        After completing and verifying the installation, use the Windows Services panel to change the IBMWAS6Service - node service to an automatic startup type.

        1. Right-click IBMWAS6Service - node and click Properties.

        2. Click Automatic from the Startup type list box and click OK.

      2. Click Run IBM HTTP Server as a service.

        Select this option on the machine where we are installing the IBM HTTP Server.

        If we select this option, the installation wizard creates the following services during the installation:

        • IBM HTTP Server 2.0.x
        • IBM HTTP Administration 2.0.x

        The installation wizard defines the startup type of these services as automatic. It is not necessary for you to change the type from manual to automatic.

      3. Enter your user ID and password and click Next.

      In a coexistence environment, we can change the default service names to make them unique. In a same version coexistence scenario for IBM HTTP Server 2.0.x on a Windows platform, we cannot use the default service names created by the installer because they are common.

      To work around this problem:

      1. Install the first copy of IBM HTTP Server, either by itself or with the product, and select to install the services.

      2. Customize the service names for the first install by running the following commands from the first install location:

          apache -k install -n "IHS 2.0(1)"
          apache -k install -f conf\admin.conf -n "IHS 2.0 Administration (1)"

      3. Edit the AdminAlias directive in the installLocation 1\conf\admin.conf file to point to the new service name, such as IHS 2.0(1).

      4. Remove the default service names installed by the first install by running the following commands:

          apache -k uninstall -n "IBM HTTP Server 2.0"
          apache -k uninstall -n "IBM HTTP Administration 2.0"

      5. Install the second copy of IBM HTTP Server, either by itself or with the product. The default service names correspond to the second install.

      Customized service names must be unique on your system.gotcha

  2. On a Linux or supported UNIX operating system, after installing the product, set up a shell script to automatically monitor and restart any related server processes. There are two sets of substeps to complete this task. The first set of substeps do not apply on the Red Hat Enterprise Linux Version 6 operating system.

    1. Locate the rc.was example shell script, located in app_server_root/bin.

    2. Create a new shell script for each process that the operating system is to monitor and restart.

    3. Edit each shell script according to comments in its header, which provide instructions for identifying a product process.

    4. As user root, edit the inittab file of the operating system, to add an entry for each shell script you have created.

      Comments in the header of the rc.was file include a sample inittab entry line for adding this script to the inittab table. Each inittab entry causes the operating system to call the specified shell script whenever the system initializes. As each shell script runs, it monitors and starts the server process we specified.

      For example, if you create the following inittab entry for a process, the rc.was shell script is run whenever the system initializes, and if the process goes down while the system is initializing into a machine operating at a runlevel of 2, 3, or 5:

        was:235:respawn:/usr/WebSphere/AppServer/bin/rc.was >/dev/console 2>&1

      If we create the following inittab entry, the rc.was shell script only runs once when you initialize into a machine operating at a runlevel of 2, 3, or 5:

        was:235:once:/usr/WebSphere/AppServer/bin/rc.was >/dev/console 2>&1

      Following is a list of the runlevels that can be specified. Runlevels usually default to either 3 or 5.

      • 0-halt
      • 1-Single user mode
      • 2-Multiuser, without NFS (The same as 3, if we don't have networking)
      • 3-Full multiuser mode
      • 4-unused
      • 5-X11
      • 6-Reboot

      If we don't know the runlevel into which the machine is booting, look at the following line in the inittab file:

        id:x:initdefault

      where x is the runlevel that the machine is booting into.

      For example, if the machine is booting into a runlevel of 5, then all of the processes that are declared to run with a runlevel of 5 are started.

      Everything that is ran from the inittab file runs under the root user. Therefore, if we need the server to automatically start the process under a non-root user ID when the machine starts, we must also add the following line to the inittab file:

        su user -c values

      where values is the file path and arguments used to call the rc scripts you created, and user is the non-root user that we have configured the product to run as.

      gotcha

    Each shell script monitors and restarts the following processes in a WAS ND environment:

    The following set of substeps apply to the Red Hat Enterprise Linux Version 6 operating system.sptcfg

    1. Create the as1.conf file to monitor and restart processes and place it in the /etc/init directory. For example...

        # upstart service for my application server profile
        description "my application server"
        start on runlevel [235]
        stop on runlevel [!235]
        expect fork
        respawn
        exec /opt/IBM/WebSphere/AppServer/bin/rc.as1

    2. Create the rc.as1 file to restart the server and place it in the install_root/bin directory for WAS. The following code is example content for the rc.as1 file:

        #!/bin/sh cd /opt/IBM/WebSphere/AppServer/profiles/profile/bin
        ./startServer.sh server

      profile represents the name of the application server profile. server is the name of the server. Change these values to match ythe environment.

  3. (Windows) After installing the product, we can use the WASService command in the app_server_root\bin directory to manually define a Windows service for another installation instance or for another configuration instance of the server1 process.

  4. (Windows) After installing the product, use the WASService.exe command to manually define the nodeagent server process as a Windows service.

    We can use the same command to manually define a Windows service for another installation instance or for another configuration instance of either the server1 process or the dmgr process.

  5. (iSeries) In the administrative console, click...

      Servers | Server Types | WebSphere application servers | server | Process

    Start the administrative console.

    In the topology tree, expand...

      Servers | Application Servers

    Click the name of the application server that you want to start automatically.

    Click...

      Process Definition | Monitoring Policy

    Change the Node Restart state to RUNNING.

    Click Apply. Save the configuration.

  6. (iSeries) To automatically restart an application server...

      application server | Server Infrastructure | Java and process management | Monitoring Policy | Automatic restart | Apply | Save

(Windows) On a Windows operating system, we can

Processes started by a startServer command, a startNode command, or a startManagercommand are not running as monitored processes, regardless of how they are configured.

For example, we can configure a server1 process as a monitored process. However, if we start the server1 process using the startServer command, the operating system does not monitor or restart the server1 process because the operating system did not originally start the process as a monitored process.


What to do next

After the process is set up, the operating system can monitor each server process and restart the process if it stops.

Return to the Defining application server processes administrative console page to continue.


Subtopics

  • Define application server processes
  • startNode command
  • startServer command
  • startManager command