Page History

...

Unzip the downloaded file to an arbitrary directory.
Directory structure (only files and folders directly relevant):
- bin
  - controller.cmd|sh
    - The start script for Windows platforms.
  - controller_watchdog.cmd|sh
    - Notes the task that is being forwarded for execution by a JS7 Controller to Agent
  - environment_variables.cmd|sh
    - includes environment variables used by JS7 Controller
- lib
  - The directory for Java libraries.
  - Configure the settings in log4j2.xml file if you want to adjust the logger settings.
- service (for Windows)
  - amd64 (directory)
  - manager (directory)
  - x86 (directory)
  - install_controller_windows_service.cmd
  - js7_controller_controller<Controller ID>.exe
  - js7_controller_controllerw<Controller ID>w.exe
  - LICENSE.txt
  - NOTICE.txt
  - RELEASE-NOTES.txt
  - set_java_home_for_jetty_windows_service.cmd
  - start_jetty_windows_service.cmd
  - uninstall_controller_windows_service.cmd
- user_bin
  - environment_variables.cmd-example - example script to set the Controller environment variables (Microsoft Windows)
- Uninstaller (the empty directory remains after uninstall)
  - install.log
  - js7.ico
  - shortcut.vbs
  - uninstall.cmd
  - uninstall_prepare.cmd
  - uninstaller.jar
- var
  - logs
  - config
  - state

On Windows Systems:

You have to change the directory permissions for the .\logs and .\service directories if you have extracted the JobScheduler Agent under e.g. C:\Program Files.

This step is not required if you extracted the Agent to e.g. C:\ProgamData.

Start a command prompt with elevated administrator rights and type e.g.

Code Block

language	bash
title	set full acces for "Users" on .\service and .\logs directory

cd "path\to\Agent installation"
icacls "service" /L /grant *S-1-5-32-545:(OI)(CI)F
icacls "logs" /L /grant *S-1-5-32-545:(OI)(CI)F

If multiple instances are configured then every instance must have its own ./var_4445 data directory (e.g. ./var_<port of the instance>)

Update of a an Agent

Preparations for an update
- Stop all JobScheduler Universal Agent instances
- Remove the ./lib directory
Unzip the downloaded file to the installation directory
If you use the Windows installer of JobScheduler Universal Agent then the ./lib directory is updated automatically during the setup. It is not necessary to remove the ./lib directory before you start the installer.

Running the Agent

SOS does not recommend running the JobScheduler Agent as root (for Unix) or as Administrator (for Windows).
Instead the user account should be used that jobs are executed for. Should jobs be executed for a number of user accounts then consider the chapter Running multiple instances of JobScheduler Universal Agent.

Usage

Running the start script without parameters shows the usage clause:

...

language	text
title	Usage for Unix

...

Update of JS7 Controller

Preparations for an update

Stop the JS7 Controller instance
When the Controller was installed previously it add a controller_install.xml file which includes the parameters such as the installation path, ports, etc.

The controller_install.xml the file is shown in the code listing below. The extensive comments are intended to be self-explanatory.

Code Block

language	xml
title	Configuration of the controller_install.xml file
linenumbers	true
collapse	true

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- 
XML configuration file for JS7 Controller setup

The JS7 Controller is available with a dual licensing model.
- GNU GPL 2.0 License (see http://www.gnu.org/licenses/gpl-2.0.html)
- JS7 Commercial License (see licence.txt)

The setup asks you for the desired license model 
(see <entry key="licenceOptions" .../> below).

If you call the setup with this XML file then you accept 
at the same time the terms of the chosen license agreement. 
-->
<AutomatedInstallation langpack="eng">
    <com.izforge.izpack.panels.UserInputPanel id="home">
        <userInput/>
    </com.izforge.izpack.panels.UserInputPanel>
    <!--com.izforge.izpack.panels.UserInputPanel id="licences">
        <userInput-->

...

<!-- Select the license model (GPL or Commercial) -->

...

<!--entry key="licenceOptions" value="GPL"/-->

...

 <!-- If you selected GPL as license model than the licence must be empty.

...

- Otherwise

...

- please

...

- enter a

...

- license

...

- key

...

- if

...

- available.

...

- It is also possible

...

- to

...

- modify the license key later. -

...

- -

...

- >

...

- <!-

...

- -

...

entry key="licence" value=""/>

...

- </userInput>

...

</com.izforge.izpack.panels.UserInputPanel-->
    <com.izforge.izpack.panels.HTMLLicencePanel id="gpl_licence"/>
    <com.izforge.izpack.panels.HTMLLicencePanel id="commercial_licence"/>
    <com.izforge.izpack.panels.TargetPanel id="target">
        
        <!--

...

- SELECT

...

- THE INSTALLATION PATH

...

        The installation expands this path with the JS7 ID

...

- as subdirectory.

...

        It must be absolute!
             For example C:\Program Files\sos-berlin.com\js7\controller -->

...

<installpath>C:\Program Files\sos-berlin.com\js7\controller</installpath>

...

    
    </com.izforge.izpack.panels.TargetPanel>
    <com.izforge.izpack.panels.UserPathPanel id="userpath">
        
        <!-- SELECT THE DIRECTORY FOR CONFIGURATION AND LOG FILES

...

- The installation expands

...

this path with the JS7 ID as subdirectory.
             The path must be absolute!
             Default path is C:\ProgramData\sos-berlin.com\js7\controller -->

...

<UserPathPanelElement>C:\ProgramData\sos-berlin.com\js7\controller</UserPathPanelElement>
        
    </com.izforge.izpack.panels.UserPathPanel>
    <com.izforge.izpack.panels.UserInputPanel id="network">
        <userInput>

...

 <!-- ID of the JS7 Controller -->
            <entry key="controllerId" value="controller"/>
            
            <!-- Choose

...

- yes

...

- if

...

- the

...

- JS7 Controller is a

...

Standby-Controller in a cluster -->
            <entry key="isStandby" value="no"/>

...

language	text
title	Usage for Windows

...

<!-- Choose (yes or no) wether the JS7 Controller should be started at the end of the installation -->

...

<entry key="launchController" value="yes"/>

...

<!-- HTTP port of the JS7 Controller -->

...

<entry key="controllerPort" value="4444"/>

...

- <!-- Set optionally

...

an ip address or hostname. It could be used for indicating which network

...

- interfaces the JS7

...

- Controller

...

- should listen to

...

when using HTTP. If it is empty then 
                 it listens to all available network interfaces. -->

...

- <entry

...

key="controllerHost" value=""/>

...

- <!-

...

- -

...

 The JS7 Controller will be installed as Windows service. You can set the service

...

- account

...

otherwise the local system account will be used. The account has to be the form

...

- 'Domain\User'. -->

...

         <entry key="serviceAccount" value=""/>
            <entry key="servicePassword" value=""/>

...

  </userInput>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.UserInputPanel id="environment">
        <userInput>

            <!-- Directory

...

- where

...

- the

...

- JS7 Controller's log files

...

are stored (default: 
                 '[above user path]\logs'). -->

...

- <entry key="logPath" value=""/>

...

          
            <!-- Directory where the JS7 Controller's pid file is stored

...

- (default:

...

             above log path). -->
            <entry key="pidFilePath" value=""/>

...

         
            <!-- Working directory for all jobs which started by the JS7 Controller
                 e.g. %USERPROFILE% (default: [installation path]) -->
            <entry key="workPath" value=""/>
            
            <!-- The JS7 Controller requires a Java JRE at least version '1.8'. You can choose 
                 a different Java environment than the Java which is used during this installation. -->
            <entry key="javaHome" value=""/>
            
            <!-- Set optionally Java options (default: -Xmx500m). -->
            <entry key="javaOptions" value=""/>
            
        </userInput>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.UserInputPanel id="end">
        <userInput/>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.InstallPanel id="install"/>
    <com.izforge.izpack.panels.ProcessPanel id="process"/>
    <com.izforge.izpack.panels.FinishPanel id="finish"/>
</AutomatedInstallation>

Batch installation is started by opening a terminal or command window in the folder containing the setup.* file and typing:
- Code Block
  language text
  title Starting batch installation of the JOC Cockpit on Linux systems with root permissions
  /tmp/controller.[release]> ./setup.sh controller_install.xml
  Code Block
  language text
  title Starting batch installation of the Controller on Linux systems without root permissions
  /tmp/controller.[release]> ./setup.sh -u controller_install.xml
- Code Block
  language text
  title Starting batch installation of the Controller on Windows systems
  C:\temp\controller.[release]> setup.cmd controller_install.xml

Usage

Running the start script without parameters shows the usage clause:

Code Block

language	text
title	Usage for Unix

Usage: controller.sh command [options]
  command:
    start         [options]
    start_docker  [options]
    stop          [options]
    abort         [options]
    restart       [options]
    status        [options]
    kill          [options]
  options:
    --id=<JS7 Controller Id>                        | default: controller
    --http-port=<[hostname or ip address:]number>   | default: 4444
    --https-port=<[hostname or ip address:]number>  | default:
    --data-directory=<location of data directory>   | default: /var/sos-berlin.com/js7/controller/var
    --config-directory=<location of data directory> | default: /var/sos-berlin.com/js7/controller/var/config
    --java-options=<java options>                   | default: -Dfile.encoding=UTF-8  -Xmx500m -Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector -Dlog4j2.asyncLoggerWaitStrategy=Block; see also https://kb.sos-berlin.com/x/aIC9
see also https://kb.sos-berlin.com/x/kQiX for more information.

Code Block

language	text
title	Usage for Unix

Usage: controller.cmd command [options]
  command:
    start           [options]
    stop            [options]
    abort           [options]
    restart         [options]
    status          [options]
    kill            [options]
    install-service [options]
    remove-service  [options]
    start-service   [options]
  options:
    --id=<JS7 Controller ID>                                    | default: controller
    --http-port=<[hostname or ip address:]number>               | default: 7444
    --https-port=<[hostname or ip address:]number>              | default:
    --data-directory=<location of data directory>               | default: C:\ProgramData\sos-berlin.com\js7\controller\controller
    --config-directory=<location of data directory>             | default: C:\ProgramData\sos-berlin.com\js7\controller\controller\config
    --java-options=<java options>                               | default: -Dfile.encoding=UTF-8  -Xmx500m -Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector -Dlog4j2.asyncLoggerWaitStrategy=Block; see also https://kb.sos-berlin.com/x/aIC9
see also https://kb.sos-berlin.com/x/kQiX for more information.

Command-Line Options

-id=<JS7 Controller ID>
- is a unique identifier for an instance of Controller within a network
-http-port=<[hostname or ip address:]number>
- is the HTTP port that the Controller is listening to in order to receive requests from JOC Cockpit and Agent
  - ```
  controller.cmd|sh command -http-port=####
```
- where #### is the numeric port.
- This option can be also used for indicating which network interfaces the JS7 Controller should listen to if you specify a hostname or IP address in addition
- Without this option being used the port defaults to 4444 and the Controller listens to all available network interfaces.
- Should you want to specify a port then the following precedence applies:
  - First precedence: command line option
  - Second precedence: environment variable JS7_CONTROLLER_HTTP_PORT (see below)
  - Third precedence: use of default value
-https-port=<[hostname or ip address:]number>
- is the HTTPS port that the Controller is listening to in order to receive requests from a Controller:
  - ```
  agent.cmd|sh command -https-port=####
```
- where #### is the numeric port.
- This option can be also used for indicating which network interfaces the Controller should listen to if you specify a hostname or IP address in addition
- Should you want to specify a port then the following precedence applies:
  - First precedence: command line option
  - Second precedence: environment variable JS7_CONTROLLER_HTTPS_PORT (see below)
  - Third precedence: use of default value
-data-directory=<number>
- Location of the data directory.
- It has to be unique over all JS7 Controller instances
- Should you want to specify a data directory then the following precedence applies:
  - First precedence: command line option
  - Second precedence: environment variable JS7_CONTROLLER_DATA (see below)
  - Third precedence: use of default value (JS7_CONTROLLER_HOME\var_JS7_CONTROLLER_HTTP_PORT)
-java-options=<java options>
- With Java 1.8 the initial memory allocation has changed, for details see How to manage the Java heap space.
- This option can be used to apply Java options for the Controller, e.g. the memory settings.
- Without this option being used the Java options default to '-Xms500m'.
- Should you want to specify the Java options then the following precedence applies:
  - First precedence: command line option
  - Second precedence: environment variable JAVA_OPTIONS (see below)
  - Third precedence: use of default value
--config-directory
- configuration files are stored.
- It has to be unique over all JS7 Controller instances
- Should you want to specify a data directory then the following precedence applies:
  - First precedence: command line option
  - Second precedence: environment variable JS7_CONTROLLER_CONFIG_DIR (see below)
  - Third precedence: use of default value (JS7_CONTROLLER_DATA\config)

Running the Controller

SOS does not recommend running the JS7 Controller as root (for Unix) or as Administrator (for Windows).

Start the Controller

Code Block

language	bash

controller.cmd|sh start [options]

Stop the Controller

Code Block

language	bash

controller.cmd|sh stop [options]

This command will safely terminate the Controller(recommended).

Code Block

language	bash

controller.cmd|sh abort [options]

The Controller process is terminated immediately.

Code Block

language	bash

controller.cmd|sh kill [options]

The controller process is killed.

This corresponds to sending SIGKILL with a kill command.

Restart the Controller

Code Block

language	bash

controller.cmd|sh restart [options]

Check the Controller Status

Code Block

language	bash

controller.cmd|sh status [options]

Should the Controller be up and running then this command will result in some output such as:

Code Block

language	bash

id: controller
version: 2.0.0-alpha.20210706 (2021-07-06)
buildId: KvsbZFR9QfOT-GAJg33fLA
startedAt: 1625646518935
totalRunningTime: 632857.312
orderCount: 1973
system:
  hostname: KA0054
  cpuModel: Intel64 Family 6 Model 94 Stepping 3, GenuineIntel
  mxBeans:
    operatingSystem:
      availableProcessors: 4
      systemLoadAverage: -1
java:
  version: 1.8.0_171
  memory:
    maximum: 501743616
    total: 501743616
    free: 420687192
  systemProperties:
    java.vendor: Oracle Corporation
    os.arch: amd64
    java.runtime.name: Java(TM) SE Runtime Environment
    os.version: '10.0'
    os.name: Windows 10
    java.vm.name: Java HotSpot(TM) 64-Bit Server VM
    java.version: 1.8.0_171

Should the Controller not be running then some output is provided such as:

Code Block
ERROR: java.nio.file.NoSuchFileException: C:\ProgramData\sos-berlin.com\js7\controller\controller\state\session-token ...JS7 Controller(controller) not started!

Monitoring Controller

See the How to perform active checks with a System Monitor such as Nagios/op5 article for information about configuring an automated status check of Controllers for monitoring purposes.

Windows Service Interface: Usage

The following information applies to batch installation on Windows systems. For installation with a GUI and user dialog see JS7 - Controller - Installation with Windows Installer.

The Controller is operable as a Windows Service. The start script of the Controller allows installing/removing the Windows Service.

Install the Windows Service

Code Block

language	bash

controller.cmd install-service [-http-port=<number>] [-ip-address=<hostname or ip address>]

This command installs the Controller's Windows Service. After the installation, you find the Windows Service with the name SOS JS7 Controller -id=<Controller ID> in the Services Manager Console. The Windows service uses the "local system" account.

Warning

During the service installation, it tries to copy the executable file for the Windows Service to the .\service directory. This operation could fail with the error "Access denied" if you have extracted the JS7 Controller to e.g. C:\Program Files\. In this case, you can change the permissions of the .\service directory or open the command prompt with elevated administrator rights and execute the above command once more.

Start the Windows Service

Code Block

language	bash

controller.cmd start-service [-http-port=<number>]

This command starts the Windows Service with the name SOS JS7 Controller -id=<Controller ID>.

Info
The `stop` command contains more than a simple `stop-service` command: the `stop` command checks whether the Controller was started through the CLI or as a Windows Service and stops the Controller accordingly. Therefore there is no `stop-service` command.

Remove the Windows Service

Code Block

language	bash

controller.cmd remove-service [-http-port=<number>]

This command removes the Windows Service. After executing this command you will not find the Windows Service with the name SOS JS7 Controller -id=<Controller ID> in the Services Manager Console any longer.

Warning

During removal of the service, it tries to remove the executable file of the Windows Service from the .\service directory. This operation could fail with the error "Access denied" if you have extracted the Agent to e.g. C:\Program Files\. In this case, you can change the permissions of the .\service directory or open the command prompt with elevated administrator rights and execute the above command once more.

Configure the Windows Service

After the installation of the Windows Service, you will find the .\service\js7_controller_<Controller ID>w.exe file. Start this program to configure the Windows Service.

Image Added

For example, goto the "Startup" tab
to modify the start parameter

Anchor
logging
logging
Logging

Log File
- On startup, the Controller creates a log file in the directory that is pointed to by the environment variable JS7_CONTROLLER_LOGS or in the var/logs subdirectory of the Controller installation directory.
- Logfile names are created from a prefix and the port used by the Controller like this:
  - controller.log
- Log files are rotated for each day (see ./lib/log4j2.xml) for which job activities occur.
- Rotated log files are assigned file names like this: controller.<yyyy-MM-dd>.log.gz
- For days where the Controller has no jobs to execute no log rotation will be performed.
PID File
- On startup, the Controller creates a PID file in the directory that is pointed to by the environment variable JS7_CONTROLLER_PID_FILE_DIR or in the log directory. The PID file contains the Process ID of the system process that the Controller is running in.
- The PID file is used in order to prevent the Controller to be started twice with the same settings and it can be used for shutdown scripts that require the PID to terminate the process.
- PID file names are created like this:
  - controller.pid
Further References
- For individual configuration of log rotation and log, retention see JS7 - Log Rotation

Anchor
js_agent_env_vars
js_agent_env_vars
Environment Variables

The following environment variables can be used:

JAVA_HOME
- points to the location of the Java Runtime Environment (JRE).
- Without setting this environment variable Java will be used from the location specified by the system path.
- Please consider that JAVA_HOME does not point to the location of a JDK but to a JRE directory where the bin/java executable resides.
JAVA_OPTIONS
- sets Java options, e.g. the Java memory settings for the Controller.
- Without setting this environment variable the Java options default to '-Xms500m'.
JS7_CONTROLLER_CONFIG_DIR
- configuration files are stored.
- It has to be unique over all JS7 Controller instances
JS7_CONTROLLER_DATA
- points to the directory where the JS7 Controller has its data directory.
- Without setting this environment variable the default value is JS7_CONTROLLER_HOME\var_JS7_CONTROLLER_HTTP_PORT
JS7_CONTROLLER_HTTP_PORT
- sets the HTTP port that the JS7 Controller is listening to.
- indicates which network interfaces the JS7 Controller should listen to if a host or IP address is specified.
- if only a port number is specified then the JS7 Controller listens to all available network interfaces via HTTP.
- Without setting this environment variable the port defaults to 4444.
JS7_CONTROLLER_HTTPS_PORT
- sets the HTTPS port that the JobScheduler Agent is listening to.
- indicates which network interfaces the JS7 Controller should listen to if a host or IP address is specified.
- if only a port number is specified then the JS7 Controller listens to all available network interfaces via HTTPS.
- Without setting this environment variable the HTTPS protocol doesn't use.
JS7_CONTROLLER_LOGS
- sets the directory where the JS7 Controller log file is created.
- This setting defaults to the directory logs in the JS7 Controller installation directory.
- For Windows systems for which the JS7 Controller is installed in the program directory that is pointed to by the %ProgramFiles% environment variable, it is recommended not to use the default setting. Instead specify a different path via the JS7_CONTROLLER_LOGS environment variable, e.g. some location in the data directory that is pointed to by the %ProgramData% environment variable.
JS7_CONTROLLER_PID_FILE_DIR
- sets the directory where the JS7 Controller pid file is created.
- This setting defaults to the directory that is specified with the JS7_CONTROLLER_LOGS environment variable or the log directory default value.

Usage Examples

Running the Controller on Windows

For Windows® operating systems the location of the Java Runtime Environment and of the log directory can be specified like this:

Code Block

language	bash

set JAVA_HOME=%ProgramFiles%\Java\jre8
set JS7_CONTROLLER_LOGS=%ProgramData%\sos-berlin.com\js7\controller\controller\var\logs
"%ProgramFiles%\sos-berlin.com\agent\js7\controller\bin\agent.cmd" start

Running the Agent on Mac OS X

For Mac® OS X the location of the Java Runtime Environment can be specified like this:

Code Block

language	bash

JAVA_HOME=/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
export JAVA_HOME
/Users/ap/Documents/js7/controller/bin/controller.sh start

Automated Start-up and Shutdown of an Agent

For Unix systems, the start-up and shutdown configurations apply that are executed by root, e.g. in /etc/init.d or corresponding locations.
- Consider the use of the JS7_USER environment variable to run a Controller that is started by root for a different user account.
For Windows systems, the start-up of the Controller by installing it as a Windows Service is recommended.

Debugging

The Controller log level can be increased using the Controller's Apache ProcRun Demon Service Manager demon/service.
On Windows systems, this is installed in the Controller service Folder and will have a name such as js7_controller_<Controller ID>w.exe where Controller ID is the unique ID for the Controller
Start the ProcRun Manager, select the Logging tab in the Manager interface and set the level to Debug.
The location of the log files has already been described above.
(Do not forget to set the debug level back to Info once finished.)

Behaviour in the event of the Controller crashing

The Controller is the component in JS7 that holds the job-related configurations and orchestrates the Agent. The outage of a Controller instance does not prevent the execution of workflows having the jobs running on a single Agent. However, it affects the execution of workflows that include jobs that are running on a number of Agents as switching of Agents during workflow execution is performed by the Controller. Refer the article JS7 - Troubleshooting - How to troubleshoot the outage of a Controller for details.

Command Line Options

-http-port=<[hostname or ip address:]number>
- is the HTTP port that the Agent is listening to in order to receive requests from a JobScheduler Master:
  - ```
  jobscheduler_agent.cmd|sh command -http-port=####
```
- where #### is the numeric port.
- This option can be also used for indicating which network interfaces the JobScheduler Agent should listen to if you specify a hostname or IP address in addition
- Without this option being used the port defaults to 4445 and the Agent listens to all available network interfaces.
- Should you want to specify a port then the following precedence applies:
  - First precedence: command line option
  - Second precedence: environment variable JS7_AGENT_HTTP_PORT (see below)
  - Third precedence: use of default value
-https-port=<[hostname or ip address:]number>
- is the HTTPS port that the Agent is listening to in order to receive requests from a Controller:
  - ```
  agent.cmd|sh command -https-port=####
```
- where #### is the numeric port.
- This option can be also used for indicating which network interfaces the Agent should listen to if you specify a hostname or IP address in addition
- Without this option being used the port defaults to 4445and the JobScheduler Agent listens to all available network interfaces.
- Should you want to specify a port then the following precedence applies:
  - First precedence: command line option
  - Second precedence: environment variable SJS7_AGENT_HTTP_PORT (see below)
  - Third precedence: use of default value
-data-directory=<number>
- Location of the data directory.
- It has to be unique over all JobScheduler Universal Agent instances
- Should you want to specify a data directory then the following precedence applies:
  - First precedence: command line option
  - Second precedence: environment variable JS7_AGENT_DATA (see below)
  - Third precedence: use of default value (=JS7_AGENT_HOME/var_<JS7_AGENT_PORT>)
-kill-script=<location of kill script>
- The kill scripts provide the functionality to kill a task and it's child processes.
- Two kill scripts are provided
  - ./bin/jobscheduler_agent_kill_task.sh for Unix as default
  - .\bin\jobscheduler_agent_kill_task.cmd for Windows as default
- This option can be used to specify the location of a different "kill script" if necessary
- Should you want to specify a different "kill script" then the following precedence applies:
  - First precedence: command line option
  - Second precedence: environment variable JS7_AGENT_KILL_SCRIPT (see below)
  - Third precedence: use of default value
-java-options=<java options>
- With Java 1.8 the initial memory allocation has changed, for details see How to manage the Java heap space.
- This option can be used to apply Java options for the Agent, e.g. the memory settings.
- Without this option being used the Java options default to '-Xms100m'.
- Should you want to specify the Java options then the following precedence applies:
  - First precedence: command line option
  - Second precedence: environment variable JAVA_OPTIONS (see below)
  - Third precedence: use of default value
-job-java-options=<java options>
- Without this option being used the Java options for each job which is started by the JobScheduler Universal Agent.
- Should you want to specify the Java options for the jobs then the following precedence applies:
  - First precedence: command line option
  - Second precedence: environment variable JS7_AGENT_JOB_JAVA_OPTIONS (see below)

Start the Agent

Code Block

language	bash

agent.cmd|sh start [options]

Stop the Agent

Code Block

language	bash

agent.cmd|sh stop [options]

This command will safely terminate the Agent (recommended).

The Agent waits for running processes to be completed.
Any child processes will be killed by the Agent.

Code Block

language	bash

agent.cmd|sh abort [options]

The Agent process is terminated immediately.

Any running tasks and child processes are killed immediately with a SIGKILL signal.
Should task have used resources such as database connections then they will not be properly closed.

Code Block

language	bash

agent.cmd|sh kill [options]

The Agent process is killed.

This corresponds to sending SIGKILL with a kill command.
Should jobs be running that started detached child processes then it is not guaranteed that child processes will be killed.

Restart the Agent

Code Block

language	bash

agent.cmd|sh restart [options]

Check the Agent Status

Code Block

language	bash

agent.cmd|sh status [options]

Should the Agent be up and running then this command will result in some output such as:

Code Block

language	bash

isTerminating: false
system:
  hostname: agenthost
  mxBeans:
    operatingSystem:
      processCpuLoad: 2.5630713121704744E-5
      availableProcessors: 4
      freePhysicalMemorySize: 311668736
      systemCpuLoad: 0.046373903924522855
      committedVirtualMemorySize: 4475301888
      totalPhysicalMemorySize: 3155517440
java:
  systemProperties:
    java.vendor: Oracle Corporation
    os.arch: amd64
    os.version: 2.6.32-220.17.1.el6.x86_64
    os.name: Linux
    java.version: 1.8.0_31
version: 1.10.0-SNAPSHOT (6956c56a535d15fcf659f293c42d22dcf92e9e12 2015-07-15 21:23:24+02:00)
startedAt: '2015-07-17T08:38:30.516Z'
totalTaskCount: 21
currentTaskCount: 0

Should the Agent not be running then some output is provided such as:

Code Block
ERROR: spray.can.Http$ConnectionAttemptFailedException: Connection attempt to localhost:4445 failed ...JS7 Agent(4445) not started!

Monitoring Agents

See the How to perform active checks with a System Monitor such as Nagios/op5 article for information about configuring an automated status check of Agents for monitoring purposes.

Master/Agent Compatibility

The Agent will raise an error if it is contacted by a Controller that is not compatible with the Agent's version.

Working Directory for Jobs

The JS7_AGENT_WORK_DIR environment variable can be used to change the jobs working directory from the default value of JS7_AGENT_HOME to a value such as $HOME (Unix) or %USEERPROFILE% (Windows).

Windows Service Interface: Usage

The following information applies to batch installation on Windows systems. For installation with a GUI and user dialog see JobScheduler Universal Agent - Installation with Windows Installer.

The Agent is operable as a Windows Service. The start script of the Agent allows to install/remove the Windows Service.

Install the Windows Service

Code Block

language	bash

agent.cmd install-service [-http-port=<number>] [-ip-address=<hostname or ip address>]

This command installs the Agent's Windows Service. After the installation you find the Windows Service with the name SOS JS7 Agent -port=<number> in the Services Manager Console. The Windows service uses the "local system" account.

Warning

During the service installation it tries to copy the executable file for the Windows Service to the .\service directory. This operation could fail with the error "Access denied" if you have extracted the JobScheduler Universal Agent to e.g. C:\Program Files\. In this case you can change the permissions of the .\service directory or open the command prompt with elevated administrator rights and execute the above command once more.

Start the Windows Service

Code Block

language	bash

agent.cmd start-service [-http-port=<number>]

This command starts the Windows Service with the name SOS JS7 Agent -port=<number>.

Info
The `stop` command contains more than a simple `stop-service` command: the `stop` command checks whether the Agent was started through the CLI or as a Windows Service and stops the Agent accordingly. Therefore there is no `stop-service` command.

Remove the Windows Service

Code Block

language	bash

agent.cmd remove-service [-http-port=<number>]

This command removes the Windows Service. After executing this command you will not find the Windows Service with the name SOS JS7 Agent -port=<number> in the Services Manager Console any longer.

Warning

During removal of the service it tries to remove the executable file of the Windows Service from the .\service directory. This operation could fail with the error "Access denied" if you have extracted the Agent to e.g. C:\Program Files\. In this case you can change the permissions of the .\service directory or open the command prompt with elevated administrator rights and execute the above command once more.

Configure the Windows Service

After the installation of the Windows Service you will find the .\service\sos_js7_agent_<http-port>w.exe file. Start this program to configure the Windows Service.

...

Image Removed

...

For example goto the "Startup" tab
to modifiy the start parameter

...

Log File
- On startup the Agent creates a log file in the directory that is pointed to by the environment variable JS7_AGENT_LOG_DIR or in the var_4445/logs subdirectory of the Agent installation directory.
- Log file names are created from a prefix and the port used by the Agent like this:
  - agent.log
- Log files are rotated for each day (see ./lib/log4j2.xml) for which job activities occur.
- Rotated log files are assigned file names like this: agent.log.<yyyy-MM-dd>
- For days where the Agent has no jobs to execute no log rotation will be performed.
PID File
- On startup the Agent creates a PID file in the directory that is pointed to by the environment variable JS7_AGENT_PID_FILE_DIR or in the log directory. The PID file contains the Process ID of the system process that the Agent is running in.
- The PID file is used in order to prevent the Agent to be started twice with the same settings and it can be used for shutdown scripts that require the PID to terminate the process.
- PID file names are created like this:
  - agent.pid
Further References
- For individual configuration of log rotation and log retention see JS7 - Log Rotation

...

The following environment variables can be used:

JAVA_HOME
- points to the location of the Java Runtime Environment (JRE).
- Without setting this environment variable Java will be used from the location specified by the system path.
- Please consider that JAVA_HOME does not point to the location of a JDK but to a JRE directory where the bin/java executable resides.
JAVA_OPTIONS
- sets Java options, e.g. the Java memory settings for the Agent.
- Without setting this environment variable the Java options default to '-Xms100m'.
JS7_AGENT_JOB_JAVA_OPTIONS
- sets Java options for each job that is started by the Agent.
JS7_AGENT_HOME
- points to the directory where the JobScheduler Agent has been installed.
- Without setting this environment variable the default value is the parent directory of the start script.
- Should you want to start the Agent from a directory different to the Agent installation directory, e.g. by copying the start script to some other location, then this environment variable has to be set in order to locate the JobScheduler Agent installation directory.
JS7_DAGENT_ATA
- points to the directory where the JobScheduler Agent has its data directory.
- Without setting this environment variable the default value is JS7_HOME/var_<JS7_HTTP_PORT>.
JS7_AGENT_HTTP_PORT
- sets the http port that the JobScheduler Agent is listening to.
- indicates which network interfaces the JobScheduler Agent should listen to if a host or ip address specified.
- if only a port number is specified then the JobScheduler Agent listens to all available network interfaces via http.
- Without setting this environment variable the port defaults to 4445.
JS7_AGENT_HTTPS_PORT
- sets the https port that the JobScheduler Agent is listening to.
- indicates which network interfaces the JobScheduler Agent should listen to if a host or ip address specified.
- if only a port number is specified then the JobScheduler Agent listens to all available network interfaces via https.
- Without setting this environment variable the https protocol doesn't use.
JS7_AGENT_USER
- sets the user account that the JobScheduler Agent is operated for. This includes running jobs with the permissions of the specified user.
- This setting is available for Unix systems only. For Windows systems the user account that runs the start script is used.
- Without setting this environment variable the user account that runs the start script is used.
- This setting can be used when running the Agent start script in system start-up and shutdown configurations that are executed by root, e.g. in /etc/init.d or corresponding locations.
JS7_AGENT_LOG_DIR
- sets the directory where the JobScheduler Agent log file is created.
- This setting defaults to the directory logs in the Agent installation directory.
- For Windows systems for which the Agent is installed in the program directory that is pointed to by the %ProgramFiles% environment variable it is recommended not to use the default setting. Instead specify a different path via the SCHEDULER_LOG_DIR environment variable, e.g. some location in the data directory that is pointed to by the %ProgramData% environment variable.
JS7_AGENT_WORK_DIR
- sets the working directory for the jobs started by the JobScheduler Agent, e.g. ${HOME} or %USERPROFILE%.
- This setting defaults to the SCHEDULER_HOME.
JS7_AGENT_KILL_SCRIPT
- sets the location of a "kill script" if required.
- The kill script provides the functionality to kill a task and it's child processes.
- Kill scripts are provided by
  - ./bin/jobscheduler_agent_kill_task.sh for Unix as default
  - .\bin\jobscheduler_agent_kill_task.cmd for Windows as default
JS7_AGENT_PID_FILE_DIR
- sets the directory where the JobScheduler Agent pid file is created.
- This setting defaults to the directory that is specified with the JS7_AGENT_LOG_DIR environment variable or the log directory default value.

Usage Examples

Running the Agent on Windows

For Windows® operating systems the location of the Java Runtime Environment and of the log directory can be specified like this:

Code Block

language	bash

set JAVA_HOME=%ProgramFiles%\Java\jre8
set SCHEDULER_LOG_DIR=%ProgramData%\sos-berlin.com\js7\agent\agent_2.0\logs 
"%ProgramFiles%\sos-berlin.com\agent\js7\agent_2.0\bin\agent.cmd" start

Running the Agent on Mac OS X

For Mac® OS X the location of the Java Runtime Environment can be specified like this:

Code Block

language	bash

JAVA_HOME=/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
export JAVA_HOME
/Users/ap/Documents/js7/agent/bin/agent.sh start

Automated Start-up and Shutdown of an Agent

For Unix systems the start-up and shutdown configurations apply that are executed by root, e.g. in /etc/init.d or corresponding locations.
- Consider use of the JS7_USER environment variable to run an Agent that is started by root for a different user account.
For Windows systems the start-up of the Agent by installing it as a Windows Service is recommended.

Debugging

The Agent log level can be increased using the Agent's Apache ProcRun Demon Service Manager demon/service.
On Windows systems this is installed in the Agent service Folder and will have a name such as sos_agent_4444w.exe where 4444 is the port the agent can be addressed over.
Start the ProcRun Manager, select the Logging tab in the Manager interface and set the level to Debug.
The location of the log files has already been described above.
(Do not forget to set the debug level back to Info once finished.)

...

Multiple instances of the JS7 Agent on the same computer can be operated, e.g. for different user accounts that jobs should be executed for.
Consider detailed instructions with the JobScheduler Universal Agent - Running multiple instances article.

Show If

group	sos-members

Any number of Agent instances can be started from the same installation, however, different ports have to be used that the Agent is listening to for requests of a JS7 Controller.
Running the Agent for different user accounts and ports
- Use the environment variable JS7_USER to operate the Agent for a user account that is different from the one that starts the Agent.
- Use the environment variable JS7_HTTP_PORT or the option -http-port=#### to start the Agent for a port that is different from the default setting.
- Make sure that the directories JS7_LOG_DIR and JS7_PID_FILE_DIR are readable and writable for the different user accounts
Add the startup options as given in the following examples to your individual startup script.

Examples for Windows

Code Block

language	bash
title	Set port by commands and options

set JAVA_HOME=%ProgramFiles%\Java\jre8
 
"%ProgramFiles%\sos-berlin.com\js7\agent\agent_2.0\bin\agent.cmd" start -http-port=4447

Code Block

language	bash
title	Set log directory and port by environment variables

set JAVA_HOME=%ProgramFiles%\Java\jre8
set JS7_LOG_DIR=%ProgramData%\sos-berlin.com\agent\jobscheduler_agent_1.10\logs
set JS7_HTTP_PORT=4445
 
"%ProgramFiles%\sos-berlin.com\js7\agent\agent_2.0\bin\agent.cmd" start

Examples for Unix

Code Block

language	bash
title	Switch user account and port by commands and options

su - js
agent.sh start -http-port=4446

Code Block

language	bash
title	Switch user account and port by environment variables

SCHEDULER_USER=js
SCHEDULER_HTTP_PORT=4446
export SCHEDULER_USER SCHEDULER_HTTP_PORT

jobscheduler_agent.sh start

Testing the JobScheduler Universal Agent Operability

A simple way to test if the installed Agent works as expected is to carry out a test using Process Classes. The Process Class and the corresponding job will be defined in your JobScheduler Master, which will connect to the JobScheduler Agent. SOS recommends to do the test locally to exclude connection problems, e.g. firewall settings, since the goal of the test is to see whether the JobScheduler Agent is working properly.

Process Class and Standalone Job

First create a Process Class, for example the following (find attached example: agent1.process_class.xml):

Code Block

language	xml
title	Example Process Class

<?xml version="1.0" encoding="ISO-8859-1"?>
<process_class  max_processes="10">
    <remote_schedulers >
        <remote_scheduler  remote_scheduler="http://localhost:4445"/>
    </remote_schedulers>
</process_class>

Important! When defining the remote JobScheduler URL, it is required to add

http://, e.g. like for the above http://localhost:4445, for HTTP communication.
https:// if you did configure secure HTTPS communication.

Second, you should define a Standalone Job and associate the Process Class as configured above to the job (find an example attached: standalone_hello.job.xml):

Code Block

language	xml
title	Example Standalone Job

<?xml version="1.0" encoding="ISO-8859-1"?>

<job  process_class="agent1">
    <script  language="shell">
        <![CDATA[
echo "hello world"
        ]]>
    </script>
    <run_time />
</job>

Finally:

store both XML files (agent1.process_class.xml and standalone_hello.job.xml) to the JobScheduler live folder in ./config/live.
start the job in JOC (start task immediately).

Find more details and use cases from the article: How to execute Jobs and Job Chains with Agents

Logs

The easiest way to check if the test was successful is to verify the contents of the job log in JOC and to see if the job completed successfully. Otherwise an error will be reported in JOC.

For double-checking you can verify the log from the JobScheduler Universal Agent. If the JobScheduler Universal Agent is running and the steps above were correctly completed then you should see something like this in the JobScheduler Universal Agent log:

Code Block

language	bash
title	JobScheduler Universal Agent Log

2020-04-28 16:11:24.462 +0200 [DEBUG] akka.io.TcpListener - New connection accepted
......
......
2020-04-28 16:13:39.231 +0200 [DEBUG] spray.can.server.HttpServerConnection - TcpConnection terminated, stopping

...

Behavior in the event of the Universal Agent crashing

It is important that all the tasks running on an Agent are killed if the Agent should crash or otherwise terminate abnormally while executing tasks. To this end, every task that is being executed by an Agent is noted by a agent_watchdog.sh agent watchdog process in a kill_tasks_after_crash.sh script. This script is located in the Agent's tmp folder and tasks are dynamically added to and deleted from the script as they are started and completed. This script is dynamically created when a first task is started by the Agent and is deleted when no tasks are running.

If an Agent crashes then the Agent Watchdog will start this script which will then cause all tasks to be killed that were running when the Agent crashed.

Space shortcuts

Page tree

Page History

Versions Compared

Old Version 3

New Version 4

Key

Update of a an Agent

Running the Agent

Usage

Update of JS7 Controller

Usage

Command-Line Options

Running the Controller

Start the Controller

Stop the Controller

Restart the Controller

Check the Controller Status

Monitoring Controller

Windows Service Interface: Usage

Install the Windows Service

Start the Windows Service

Remove the Windows Service

Configure the Windows Service

AnchorloggingloggingLogging

Anchorjs_agent_env_varsjs_agent_env_varsEnvironment Variables

Usage Examples

Running the Controller on Windows

Running the Agent on Mac OS X

Automated Start-up and Shutdown of an Agent

Debugging

Behaviour in the event of the Controller crashing

Command Line Options

Start the Agent

Stop the Agent

Restart the Agent

Check the Agent Status

Monitoring Agents

Master/Agent Compatibility

Working Directory for Jobs

Windows Service Interface: Usage

Install the Windows Service

Start the Windows Service

Remove the Windows Service

Configure the Windows Service

Usage Examples

Running the Agent on Windows

Running the Agent on Mac OS X

Automated Start-up and Shutdown of an Agent

Debugging

Examples for Windows

Examples for Unix

Testing the JobScheduler Universal Agent Operability

Process Class and Standalone Job

Logs

Behavior in the event of the Universal Agent crashing

See also

Anchor
logging
logging
Logging

Anchor
js_agent_env_vars
js_agent_env_vars
Environment Variables