Administering › Monitoring › Service Manager

Service Manager

The ServiceManager command-line utility lets you perform various actions on a registry, coordinator, simulator, or VSE server.

ServiceManager [--command]=service-name

The service-name is the name of the service to affect.

The command/name pair can be repeated.

To look up the name, wrap a lisa.properties key with double braces. For example:

{{lisa.registryName}}

Example service names:

• tcp://localhost:2010/Registry
• Simulator (resolves to tcp://localhost:2014/Simulator)

Service Manager Options

-h, --help

Displays help text.

-s service-name, --status=service-name

Displays a status message about the service. Entering all for the service-name returns status messages about all registered services.

-r service-name, --reset=service-name

Keeps the service in memory but refreshes its state.

-o service-name, --stop=service-name

Instructs the service to end.

-i valid-remote-init-service-name, --initialize=valid-remote-init-service-name

Remotely initializes a service.

-t service-name, --threaddump=service-name

Instructs the service to generate a thread dump (stack trace) for diagnostics.

-b simulator-name, --attached=simulator-name

Instructs simulator-name to return a list of attached mobile devices.

-e service-name, --heapdump=service-name

Instructs the service to create an .hprof file for memory diagnostics.

-g service-name, --gc=service-name

Instructs the service to force a Java garbage collection.

-d service-name, --diagnostic=service-name

Creates a zip file that contains diagnostic files for the service. If the service is a registry, then the zip file also contains diagnostic files for all connected coordinators, simulators, and VSE servers. Typically, you use this option when requested to do so by Support.

loglevel

This option also includes an optional, secondary parameter that is named loglevel, followed by one of the following loglevel keywords: error, warn, info, debug, trace.

For example, ServiceManager -d tcp://10.1.1.23:2010/Registry loglevel debug sets the log level of all components, including agents, to the debug level. Service Manager then writes the following message:

Log levels set to debug. Run your repro steps, then press return to restore log levels and capture diagnostic.

The generated zip file contains debug log level logs for all connected components and thread dumps and license information and properties. This zip file also contains the logs for any agents that are connected to the registry broker.

Note: If the -d command is sent to a VSE, coordinator, or simulator server, only the logs and diagnostics for that component are included in the zip.

Agents do not have a trace log level, but the dev log level is similar and treated as such.

-u username, --username=username

Use this command to specify your user name.

-p password, --password=password

Use this command to specify your password.

--version

Print the version number.

-m registry-name, --registry-name=registry-name

Used with initialize to specify a registry to which to attach.

-n component-name, --component-name=registry-name

Used with initialize to specify a component name.

-l lab-name, --lab-name=lab-name

Used with initialize to specify a lab name to create.

-a app-name, --app=app-name

Used with initialize to specify a server appID.

Example:

If you have a simulator that you want to name MySim and you want to attach it to MyRegistry and start a new lab that is named MyDevLab, enter:

./SimulatorService -n MySim -m tcp://1.2.3.4:2010/MyRegistry -l MyDevLab

To add a second simulator to that lab:

./SimulatorService —component-name=MySecondSim —registry-name=tc;"//1.2.3.4:2010/MyRegistry —lab-name=MyDevLab

To add a VSE to that registry but in a different lab:

./VirtualServiceEnvironment -n CoreServices -m tcp://1.2.3.4:2010/MyRegistry -l QA

Service Manager Examples

The following example checks the status of the registry.

ServiceManager -s Registry
Coordinator Servers: 1 Simulator Servers: 2 VSEs: 1 Running vusers: 0
Labs: 1 Memory used 76mb, allocated 155mb, max 253mb (30%)
labSims: 2 labVSEs: 1 labCoords: 1

The following example checks the status of all registered services.

Coordinator Server: tcp://bdert-mbp.local:2011/Coordinator
OK: 1 Coordinators running. Memory used 223mb, allocated 461mb, max 910mb (24%) Our cpu usage 0%, system cpu used 8%
Simulator Server: tcp://bdert-mbp.local:2014/Simulator
OK: 1 Simulators running. Memory used 301mb, allocated 437mb, max 910mb (33%) Our cpu usage 0%, system cpu used 8%

The following example stops the registry.

ServiceManager -o Registry
Sending stop request to Registry.

The following example generates a thread dump for the VSE server.

ServiceManager --threaddump=tcp://remote.host.com:2013/VSE
< a bunch of stack traces >

The following example forces a Java garbage collection for the VSE server.

ServiceManager --gc=VSE
After GC: Memory used 55mb, allocated 225mb, max 246mb (22%)

The following example generates a zip file that contains trace level logs for all components that are connected to the registry.

ServiceManager --diagnostic=Registry loglevel TRACE

The following example generates a zip file that contains debug level logs for the simulator.

ServiceManager -d Simulator loglevel debug