|
|
WebLogic Server provides several ways to start and stop server instances. The method that you choose depends on whether you prefer using the Administration Console or a command-line interface, and on whether you are using Node Manager to manage the server’s life cycle.
No matter how you start a server, the end result passes a set of configuration options to initialize a Java Virtual Machine (JVM). The server instance runs within the JVM, and the JVM can host only one server instance.
| Note: | For procedures that require the Administration Console, see Start and Stop Servers and various startup and shutdown procedures in the Cluster section of the Administration Console Online Help. For information on restarting failed server instances and clusters, see Avoiding and Recovering From Server Failure. |
The following sections describe other methods of starting and stopping server instances:
For a concise overview of starting and stopping servers, see Starting and Stopping Servers: Quick Reference.
Depending on the method you choose to manage server startup and what setup tasks you have already performed, you might need to complete the following procedures before you can start server instances:
The Administration Server and all Managed Servers in a domain must be the same WebLogic Server version. The Administration Server must be either at the same service-pack level or at a later service-pack level than the Managed Servers. For example, if the Managed Servers are at version 8.1, then the Administration Server can be either version 8.1, 8.1 SP1 or higher. However, if the Managed Servers are at SP1, then the Administration Server must be at SP1 or higher.
An Administration Server is a WebLogic Server instance that maintains configuration data for a domain. In a development environment, it is usually sufficient to start an Administration Server and deploy your applications directly onto the Administration Server. In a production environment, you create Managed Servers to run applications. For more information about Administration Servers and Managed Servers, see Understanding WebLogic Server Domains in Understanding Domain Configuration.
You can start an Administration Server with a default startup script or create your own. To start an Administration Server with the WebLogic Server-included startup script:
See Creating WebLogic Domains Using the Configuration Wizard or Creating Domains Using WLST Offline in WebLogic Scripting Tool.
By default, this directory is BEA_HOME\user_projects\domains\DOMAIN_NAME, where DOMAIN_NAME is the root directory of the domain. (The name of this directory is the name of the domain.)
| Note: | If you use a Configuration Wizard template that is provided by WebLogic Server, your domain directory includes a start script named startWebLogic. If you use a domain template from another source, the wizard might not create a start script, or it might create a script with a different name. The template designer determines whether the wizard creates a start script and the name of the script. |
The startWebLogic script does the following:
DOMAIN_NAME\bin\setDomainEnv.cmd (setDomainEnv.sh on UNIX), where DOMAIN_NAME is the directory in which you located the domain; for example, WL_HOME\user_projects\domains\DOMAIN_NAME, and where WL_HOME is the location in which you installed WebLogic Server.java weblogic.Server command, which starts a JVM that is configured to run a WebLogic Server instance.When the server successfully completes its startup process, it writes the following message to standard out (which, by default, is the command window):
<Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>
When you create an Administration Server on a Windows computer, the Configuration Wizard creates a shortcut on the Start Menu for starting the server (User Projects
DOMAIN_NAMEStart Admin Server for WebLogic Domain).
The command that the Configuration Wizard adds to the Start menu opens a command window and calls the startup script that is described in Starting an Administration Server with a Startup Script. When the server has successfully completed its startup process, it writes the following message to standard out (which, by default, is the command window):
<Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>
The weblogic.Server class is the main class for a WebLogic Server instance. You start a server instance by directly invoking weblogic.Server in a Java command.
| Note: | Oracle recommends using java weblogic.Server primarily for initial development but not as a standard mechanism for starting production systems for the following reasons: |
For more information, see weblogic.Server Command-Line Reference and Using the weblogic.Server Command Line to Start a Server Instance in Command Reference.
Node Manager is a utility for remote control of WebLogic Server instances. Using Node Manager you can control and monitor Managed Servers and also, start, stop, and restart Administration Servers.
You can access these Node Manager features using the WebLogic Scripting Tool commands and scripts. If you use the
nmStart command with WLST connected to a Node Manager, Node Manager supports monitoring, stopping, and restarting the Administration Server.
Using WLST and Node Manager to Manage Servers in WebLogic Scripting Tool describes how to start the Administration Server with WLST and Node Manager. How Node Manager Starts an Administration Server in the Node Manager Administrator’s Guide describes how Node Manager accomplishes this process.
The WebLogic Server custom installation process optionally installs and starts Node Manager as a Windows service on Windows systems. Oracle recommends running Node Manager as an operating system service so that it automatically restarts in the event of system failure or reboot, and using Node Manager to start and restart both Administration and Managed Servers.
For more information, see Installing the Node Manager Windows Service in the Installation Guide and Restart Administration and Managed Servers in the Node Manager Administrator’s Guide.
The WLST
startServer command starts the Administration Server without using Node Manager. The server runs in a separate process from WLST; exiting WLST does not shut down the server. See
Starting an Administration Server Without Node Manager in WebLogic Scripting Tool.
A Managed Server is a WebLogic Server instance that runs deployed applications. It refers to the Administration Server for all of its configuration and deployment information. Usually, you use Managed Servers to run applications in a production environment.
For more information about Managed Servers and Administration Servers, see Understanding WebLogic Server Domains in Understanding Domain Configuration.
If you use one of the Configuration Wizard templates that WebLogic Server provides, your domain directory includes a start script named startManagedWebLogic that you can use to start Managed Servers. You can use this script to start all the Managed Servers in a cluster.
For more information on domain directory files, see Domain Configuration Files in Understanding Domain Configuration.
This script does not use the Node Manager to start and manage the server. Instead, it uses a Java command to invoke the weblogic.Server class, which is the main class for a WebLogic Server instance. For information about invoking weblogic.Server in a Java command, see
weblogic.Server Command-Line Reference in WebLogic Server Command Reference.
To use the WebLogic Server scripts to start Managed Servers:
See Creating WebLogic Domains Using the Configuration Wizard or Create Managed Servers in the Administration Console Online Help.
startManagedWebLogic script:DOMAIN_NAME\bin\startManagedWebLogic.cmd (Windows)DOMAIN_NAME/bin/startManagedWebLogic.sh (UNIX)
where DOMAIN_NAME is the directory in which you located the domain. By default, this directory is BEA_HOME\user_projects\domains\DOMAIN_NAME.
startManagedWebLogic.cmd managed_server_name admin_url (Windows)startManagedWebLogic.sh managed_server_name admin_url (UNIX)
where managed_server_name specifies the name of the Managed Server and admin_url specifies the listen address (host name or IP address) and port number of the domain’s Administration Server.
For example, the following command uses startManagedWebLogic.cmd to start a Managed Server named myManagedServer. The listen address for the domain’s Administration Server is AdminHost:7001:
c:\bea\user_projects\domains\mydomain\bin\startManagedWebLogic.cmd myManagedServer http://AdminHost:7001
For information on running Managed Servers on a remote WebLogic Server host, see Creating and Starting a Managed Server on a Remote Machine in Create Templates and Domains Using the Pack and Unpack Commands.
For information on configuring a connection to the Administration Server, see Configuring Managed Server Connections to the Administration Server.
The startManagedWebLogic script does the following:
startWebLogic script, which sets the environment variables by invoking WL_HOME\user_projects\domains\DOMAIN_NAME\bin\setDomainEnv.cmd (setDomainEnv.sh on UNIX), where WL_HOME is the location in which you installed WebLogic Server. java weblogic.Server command, which starts a JVM that is configured to run a WebLogic Server instance.When the server successfully completes its startup process, it writes the following message to standard out (which, by default, is the command window):
<Notice> <WebLogicServer> <000360> <Server started in RUNNING mode>
To use the Administration Console to start a Managed Server, see Start Managed Servers from the Administration Console in the Administration Console Online Help.
To start Managed Servers and clusters using WLST and Node Manager, see Using Node Manager to Start Managed Servers in a Domain or Cluster in WebLogic Scripting Tool. For detailed information about WebLogic Server clusters, see Setting up WebLogic Clusters in Using Clusters.
The weblogic.Server class is the main class for a WebLogic Server instance. You start a server instance by directly invoking weblogic.Server in a Java command. See
weblogic.Server Command-Line Reference and
Using the weblogic.Server Command Line to Start a Server Instance in Command Reference.
Usually, a Managed Server contacts the Administration Server during its startup sequence to retrieve its configuration information. If a Managed Server cannot connect to the Administration Server during startup, it can retrieve its configuration by reading its locally cached configuration data from the config directory.
| Note: | The first time you start a Managed Server instance, it must be able to contact the Administration Server. Thereafter, the Managed Server instance can start even if the Administration Server is unavailable. |
For more information on starting Managed Servers when the Administration Server is unavailable, see Starting a Managed Server When the Administration Server Is Not Accessible.
To start and stop a WebLogic Server instance, you must provide the credentials of a user who is permitted to start and stop servers for the domain. For information on user credentials, roles, and permissions, see Users, Groups, and Security Roles in Securing WebLogic Resources Using Roles and Policies.
Table 2-1 describes providing user credentials when starting a WebLogic Server instance.
This section describes the following tasks:
When you create a domain, the Configuration Wizard prompts you to provide the username and password for an initial administrative user. The Configuration Wizard does the following with this information:
The Administrators group grants the highest level of privileges for starting and managing WebLogic Server. For information on administrative privileges, see Users, Groups, And Security Roles in Securing WebLogic Resources Using Roles and Policies.
myrealm security realm.
A security realm is a collection of components (providers) that authenticate usernames, determine the type of resources that the user can access, and provide other security-related services for WebLogic resources. WebLogic Server installs the myrealm security realm and uses it by default.
You can use the Administration Console to add users to security realms. If you use an Authentication provider other than the one that WebLogic Server installs, you must use the provider’s administration tools to create at least one user with administrative privileges.
security directory of the Administration Server’s root directory. The boot identity file contains an encrypted version of the username and password which lets you bypass the login prompt during subsequent instantiations of the server. See Boot Identity Files.In production domains, you are prompted to enter user credentials on the command line when booting the server.
A boot identity file is a text file that contains user credentials for starting and stopping an instance of WebLogic Server. An Administration Server can refer to this file for user credentials instead of prompting you to provide them. Because the credentials are encrypted, using a boot identity file is much more secure than storing unencrypted credentials in a startup or shutdown script. If there is no boot identity file when starting a server, the server instance prompts you to enter a username and password.
If you start a Managed Server from a script that invokes the java weblogic.Server command (or if you invoke the java weblogic.Server command directly), a Managed Server can also refer to a boot identity file. If the Managed Server and Administration Server use the same root directory, the Managed Server can refer to the Administration Server's boot.properties file. If a Managed Server's security directory contains a valid boot.properties file, it uses this file during its startup process by default. The boot.properties file can be different for each server instance in the domain.
If you use the Node Manager to start a Managed Server, the Node Manager encrypts and saves the credentials with which it started the server in a server-specific boot.properties file for use in automatic restarts. This file is located in DOMAIN_NAME/servers/SERVER_NAME/data/nodemanager, where DOMAIN_NAME is the name of the directory in which you located the domain and SERVER_NAME is the name of the server. For more information, see
Node Manager Configuration and Log Files in the Node Manager Administrator’s Guide.
The following sections describe working with boot identity files:
If you use the Configuration Wizard to create a domain in development mode, the Configuration Wizard creates an encrypted boot identity file in the security directory of the Administration Server’s root directory. For more information on domain directory files, see
Domain Directory Contents in Understanding Domain Configuration.
If a boot identity file for an Administration Server does not already exist, and if you want to bypass the prompt for username and password, create one as follows.
During the Administration Server's initial startup process, it generates security files that must be in place before a server can use a boot identity file.
username=username password=password
The username and password values must match an existing user account in the Authentication provider for the default security realm and must belong to a role that has permission to start and stop a server. For information on roles and permissions, see Users, Groups, And Security Roles in Securing WebLogic Resources Using Roles and Policies.
If you save the file as boot.properties and locate it in the security directory of the server’s root directory, the server automatically uses this file during its subsequent startup cycles. For more information, see How a Server Uses a Boot Identity File at Startup.
The first time you use this file to start a server, the server reads the file and then overwrites it with an encrypted version of the username and password.
| Note: | Use this technique only if you invoke the java weblogic.Server command from the command line. If you use a script to start an Administration Server, Oracle recommends that you do not use the technique described in this section for the following reasons: |
Instead of following the steps in the previous section, Creating a Boot Identity File for an Administration Server, you can create a boot identity file by invoking the weblogic.Server class directly on the command line and including the following options in the Java command:
-Dweblogic.management.username=username-Dweblogic.management.password=password
-Dweblogic.system.StoreBootIdentity=true
These options cause the server instance to boot with the supplied user credentials and then store them in a file named boot.properties.
For example, the following command starts an Administration Server named myAdminServer and creates a boot identity file:
java -Dweblogic.management.username=weblogic-Dweblogic.management.password=weblogic-Dweblogic.system.StoreBootIdentity=true
-Dweblogic.Name=myAdminServer weblogic.Server
For more information about invoking the weblogic.Server class directly from a command line, see
weblogic.Server Command-Line Reference in Command Reference.
If a Managed Server uses the same root directory as the Administration Server, it can use the same boot properties file as the Administration Server. If you use a Node Manager to start a Managed Server, you do not need to create a boot identity file. For more information, see Node Manager Configuration and Log Files in the Node Manager Administrator’s Guide.
To create a boot identity file for a Managed Server instance:
security directory of the Administration Server’s domain and root directories. If the files are not present, the Administration Server generates them.For more information on domain directory files, see Domain Configuration Files in Understanding Domain Configuration.
username=username password=password
The username and password values must match an existing user account in the Authentication provider for the default security realm and must belong to a role that has permission to start a server. For information on roles and permissions, see Users, Groups, And Security Roles in Securing WebLogic Resources Using Roles and Policies.
If you save the file as boot.properties and locate it in the security directory of the server’s root directory, the server automatically uses this file during its subsequent startup cycles. For more information, see How a Server Uses a Boot Identity File at Startup.
The first time you use this file to start a server, the server reads the file and then overwrites it with an encrypted version of the username and password.
A server instance uses a boot identity file during its startup process as follows:
security directory contains a valid boot.properties file, it uses this file during its startup process by default. For information about a server’s root directory, see
A Server’s Root Directory in Understanding Domain Configuration.security directory), you can include the following argument in the server’s weblogic.Server startup command:
-Dweblogic.system.BootIdentityFile=filename
where filename is the fully qualified pathname of a valid boot identity file.
To specify this argument in the startWebLogic script, add -Dweblogic.system.BootIdentityFile as a value of the JAVA_OPTIONS variable. For example:set JAVA_OPTIONS=-Dweblogic.system.BootIdentityFile=C:\BEA\user_domains\mydomain\myidentity.prop
weblogic.Server startup command:
-Dweblogic.management.username=username-Dweblogic.management.password=password
These options cause a server instance to ignore any boot identity files and override other startup options that cause a server to use boot identity files during it startup cycle.
| Note: | If you use a script to start a server instance, Oracle recommends that you do not use this technique because it requires you to store an unencrypted password in the startup script. Use this technique only if you invoke the weblogic.Server class directly from the command line. For more information, see
weblogic.Server Command-Line Reference in Command Reference. |
For a given server instance, use only the boot identity file that the instance has created. WebLogic Server does not support copying a boot identity file from one server root directory to another.
For example, if you use ServerA to generate a boot identity file, use only that boot identity file with ServerA. Do not copy ServerA’s boot identity file into the security directory of ServerB. Instead, create a boot identity file for ServerB as described in Creating a Boot Identity File for an Administration Server or Creating Boot Identity Files for Managed Servers.
If you want to remove the boot identity file after a server starts, you can include the following argument in the server’s weblogic.Server startup command:
-Dweblogic.system.RemoveBootIdentity=true
This argument removes only the file that the server used to start. For example, if you specify -Dweblogic.system.BootIdentityFile=c:\secure\boot.MyServer, only boot.MyServer is removed, even if the server’s root directory contains a file named boot.properties. Open a separate command shell and include the -Dweblogic.system.RemoveBootIdentity=true argument in each Managed Server’s weblogic.Server startup command to remove its boot identity file.
To specify this argument in the startWebLogic script, add -Dweblogic.system.RemoveBootIdentity=true as a value of the JAVA_OPTIONS variable. For example:set JAVA_OPTIONS=-Dweblogic.system.RemoveBootIdentity=true
If you use the Node Manager to start a Managed Server, you must provide user credentials on the server’s ConfigurationServer Start page of the Administration Console. If you do not provide these credentials, the Node Manager throws an exception when it tries to start the server.
When you use the Administration Console or the Configuration Wizard to create a Managed Server, WebLogic Server adds the user credentials to the server’s ConfigurationServer Start page. If you want the server instance to run under a different WebLogic Server user account, see
Configure startup arguments for Managed Servers in the Administration Console Online Help.
The following sections describe miscellaneous startup tasks:
There are two methods for making java classes globally available to WebLogic Server:
You can specify either or both of these methods. When specifying both, classes defined via the startup option take precedence.
Both are available in development and production modes. However, dynamic class loading is generally used in development environments, while the classpath method is preferable in production environments.
In both cases, you must ensure that your classes are packaged into .jar files.
If you will be starting a Managed Server from a script that invokes the java weblogic.Server command, or if you invoke the java weblogic.Server command directly, you must make sure that the Managed Server specifies the correct listen address of the Administration Server. A Managed Server uses this address to retrieve its configuration from the Administration Server.
Use the following format to specify the listen address:
[protocol://]Admin-host:port
| Note: | Regardless of which protocol you use, the initial download of a Managed Server’s configuration is over HTTP or HTTPS. After the RMI subsystem initializes, the server instance can use the T3 or T3S protocol. |
Admin-host, specify any of the following:localhost.Valid only if you are starting the Managed Server on the same computer as the Administration Server.
Because of the following security issue, Oracle recommends that you do not use IP addresses for Admin-host in a production environment:
To connect to the Administration Server through an SSL port, the Managed Server verifies that the Administration Server’s host name matches the host name that is specified in the URL. If you specify an IP address, and if host name verification is enabled, the connection fails because the IP address, which is a series of numbers, does not match the name of the host, which is a string of characters.
In a development environment, where security is less of a concern, you can disable host name verification on the Managed Server so SSL connections that specify an IP address will succeed. See Using Hostname Verification in Securing WebLogic Server.
If the Administration Server has been configured to use some other listen address, you must specify the configured listen address.
port, specify any of the following:When configured, the administration port is used by each Managed Server in the domain exclusively for communication with the domain's Administration Server. See Configure the domain-wide administration port in the Administration Console Online Help.
If you have enabled the domain-wide administration port, you must specify this port. You must specify either the T3S or HTTPS protocol to use this port.
7001 by default). If this listen port has been disabled for the Administration Server, you must use one of the other listen ports described in this list. You must specify either the T3 or HTTP protocol to use this port.
7002 by default).If this listen port has been disabled for the Administration Server, you must use one of the other listen ports described in this list. You must specify either the T3S or HTTPS protocol to use this port.
If the port is secured with SSL, you must specify either the T3S or HTTPS protocol.
<Nov 5, 2004 12:16:04 PM EST> <Notice> <Server> <BEA-002613> <Channel "DefaultSecure[2]" is now listening on 127.0.0.1:7012 for protocols iiops, t3s, ldaps, https.>
<Nov 5, 2004 12:16:04 PM EST> <Notice> <WebLogicServer> <BEA-000331> <Started WebLogic Admin Server "MedRecServer" for domain "medrec" running in Development Mode>
For information on enabling SSL, see Set up SSL in the Administration Console Online Help. For more information on network channels, see Understanding Network Channels in Configuring Server Environments.
You use Java options to configure operating parameters for the JVM that runs a WebLogic Server instance. For example, you use Java options to tune the performance and monitoring capabilities of the JRockit JVM.
You can also use Java options to override a server’s configuration temporarily. The Java options apply only to the current instance of the server. They are not saved in the domain’s config.xml file and they are not visible from the Administration Console. For example, if a server is configured to listen on port 7201, you can use a Java option to start the server so that it listens on port 7555. The Administration Console will still indicate that the server is configured to listen on port 7201. If you do not use the Java option the next time you start the server, it will listen on port 7201.
If you use a WebLogic Server script to start servers, do the following. If you use the Node Manager to start servers, see Set Java options for servers started by Node Manager in the Administration Console Online Help.
DOMAIN_NAME\bin\startWebLogic.cmd (startWebLogic.sh on UNIX) DOMAIN_NAME\bin\startManagedWebLogic.cmd (startManagedWebLogic.sh on UNIX)
where DOMAIN_NAME is the name of the directory in which you located the domain. By default, this directory is BEA_HOME\user_projects\domains\DOMAIN_NAME.
set JAVA_OPTIONS command to specify the Java options. If you specify multiple options, separate each option by a space, and place quotes around the entire set of options. For example:set JAVA_OPTIONS=“-Xgc:gencopy -Xns:30” When you create a domain, if you choose to customize the configuration, the Configuration Wizard presents a list of SDKs that WebLogic Server installed. From this list, you choose the JVM that you want to run your domain, and the wizard configures the Oracle start scripts based on your choice.
After you create a domain, if you want to use a different JVM, you can modify the scripts as follows:
JAVA_HOME variable.
Specify an absolute pathname to the top directory of the SDK that you want to use. For example, c:\bea\jrockit90.
On a Windows or Linux platform, Oracle recommends the following JVMs:
JAVA_VENDOR variable.Specify the vendor of the SDK. Valid values depend on the platform on which you are running. For more information, see the WebLogic Platform Supported Configurations page at the following URL: http:/e-docs.bea.com/platform/suppconfigs/index.html.
BEA indicates that you are using the JRockit SDK. It is valid only on platforms that support JRockit.Sun indicates that you are using the Sun SDK.HP and IBM indicate that you are using SDKs that Hewlett Packard or IBM have provided. These values are valid only on platforms that support HP or IBM SDKs.
It is recommended that you shutdown WebLogic Server instances through the Administration Console. See Shut Down a Server Instance, Control Graceful Shutdowns, and Shutdown servers in a cluster in the Administration Console Online Help.
On Windows, you can stop Administration Servers that you have created using the Configuration Wizard from the Start menu.
If you use a Configuration Wizard template that is provided by WebLogic Server, the bin directory under your domain directory includes a stop script named stopWebLogic that you can use to stop an Administration Server and one named stopManagedWebLogic for stopping Managed Servers. To use the scripts, you must set SERVER_NAME, ADMIN_URL, USERID, and PASSWORD as environment variables or specify them on the command line. When using the stopWebLogic script, if you do not specify SERVER_NAME, the Administration Server name is used by default.
DOMAIN_NAME\bin\stopWeblogic.cmd username password admin_url (Windows)DOMAIN_NAME/bin/stopWeblogic.sh username password admin_url (UNIX)
DOMAIN_NAME\bin\stopManagedWeblogic.cmd managed_server_name admin_url username password (Windows) DOMAIN_NAME/bin/stopManagedWeblogic.sh managed_server_name admin_url username password (UNIX)
| Note: | On the command line, specify parameters in the order shown. User credentials come before the ADMIN_URL with stopWebLogic.cmd and after the ADMIN_URL with stopManagedWebLogic.cmd. |
Each WebLogic Server instance runs in its own JVM. If you are unable to shut down a server instance using the methods described in the previous sections, you can use an operating system command to kill the JVM.
| Caution: | If you kill the JVM, the server immediately stops all processing. Any session data is lost. If you kill the JVM for an Administration Server while the server is writing to the config.xml file, you can corrupt the config.xml file. |
Some common ways to kill the JVM are as follows:
|