You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 54 Next »

Installing the JobScheduler Agent

  • Prerequisites
    • A Java Runtime Environment starting from version 1.8 is required.
    • Choose the JobScheduler Agent for your platform from the Downloads section.
  • Installation
    • Unzip the downloaded file to an arbitrary directory.
    • Directory Structure
      • bin
        • jobscheduler_agent.cmd
          • The start script for Windows platforms.
        • jobscheduler_agent.sh
          • The start script for Unix platforms.
      • lib
        • The directory for Java libraries.
        • Consider the settings in logback.xml should you want to adjust the log output format.
      • logs
      • service (for Windows)
    • On Windows 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 necessary if you have extracted the JobScheduler Agent under e.g. C:\ProgamData.
      • Start a command prompt with elevated administrator permissions and type e.g. ...

        set full acces for "Users" on .\service and .\logs directory
        cd "path\to\JobScheduler 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 

Running the JobScheduler Agent

  • SOS does not recommend to run 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 Agent.

Usage

Running the start script without parameters shows the usage clause:

usage on Unix
Usage: jobscheduler_agent.sh command [options]
  command:
    start           [options]
    stop            [options]
    restart         [options]
    status          [options]
 options:
    -http-port=<number> | default: 4445
usage on Windows
Usage: jobscheduler_agent.cmd command [options]
  command:
    start           [options]
    stop            [options]
    restart         [options]
    status          [options]
    install-service [options]
    remove-service  [options]
    start-service   [options]
 options:
    -http-port=<number> | default: 4445

Start the Agent

jobscheduler_agent.cmd|sh start [options]

Stop the Agent

jobscheduler_agent.cmd|sh stop [options]

For production releases this command will safely terminate the Agent waiting for running processes to be completed.

Alternatively the Agent process can be terminated by use of operating system mechanisms. Consider that these mechanisms are unaware of running processes that would be terminated with the Agent.

  • Automatically on system shutdown
  • By terminating the Agent, e.g.
    • Windows taskkill utility
      • Examples

        Run the utility for a specific Agent pid
        taskkill.exe /pid 1234
        Run the utiilty for the Agent pid that was saved on startup and enforce termination
        SET /P PID_FROM_FILE= < %SCHEDULER_LOG_DIR%\jobscheduler_agent_%SCHEDULER_HTTP_PORT%.pid
        taskkill.exe /pid %PID_FROM_FILE% /f
    • Unix kill utility
      • Examples

        Run the utility for a specific Agent pid
        kill -15 1234
        Run the utiilty for the Agent pid that was saved on startup and enforce termination
        kill -9 $(cat ${SCHEDULER_LOG_DIR}/jobscheduler_agent_${SCHEDULER_HTTP_PORT}.pid)

Restart the Agent

jobscheduler_agent.cmd|sh restart [options]

Query the Agent Status

jobscheduler_agent.cmd|sh status [options]

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

...JobScheduler Agent(4445) is running with pid=12112!

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

...JobScheduler Agent(4445) is down!

Windows Service Interface: Usage 

The Java based JobScheduler Agent is operable as a Windows Service from the version TP3 of the Agent on. The start script of the JobScheduler Agent allows to install/uninstall the Windows Service:

Install the Windows Service

jobscheduler_agent.cmd install-service [-http-port=<number>]

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

During the service installation it tries to copy the executable for the Windows service into the .\service directory. That can fail with the error "Access denied" if you have extracted the JobScheduler Agent under e.g. C:\Program Files\. In this case you can change the permissions of the .\service directory or you open the command prompt with elevated administrator permissions and call above command again.

Start the Windows Service

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

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

The stop command contains more than a simple stop-service command: the stop command it checks whether the Agent was started through the CLI (and kill the process) or as a Windows Service (and stops the Windows Service). There is no stop-service command.

Remove the Windows Service

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

This command uninstalls the Windows Service. After executing this command you will not find the Windows Service with the name SOS JobScheduler Agent -port=<number> in the Services Manager Console anymore.

During the service uninstallation it tries to remove the executable of the Windows service from the .\service directory. That can fail with the error "Access denied" if you have extracted the JobScheduler Agent under e.g. C:\Program Files\. In this case you can change the permissions of the .\service directory or you open the command prompt with elevated administrator permissions and call above command again.

 

Logging

  • Log File
    • On startup the Agent creates a log file in the directory that is pointed to by the environment variable SCHEDULER_LOG_DIR or in the logs subdirectory of the Agent installation directory.
    • Log file names are created from a prefix and the port used by the Agent like this:
      • jobscheduler_agent_4445.log
    • Log files are rotated for each day and are kept for one week (see ./lib/log4j.xml).
    • Rotated log files get the name of the form jobscheduler_agent_4445.log.<yyyy-MM-dd>
  • Pid File
    • On startup the Agent creates a pid file in the directory that is pointed to by the environment variable SCHEDULER_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 from a prefix and from the port used by the Agent like this:
      • jobscheduler_agent_4445.pid

Command Line Options

  • The only available option 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.
  • Without this option being used the port defaults to 4445.
  • Should you want to specify a port then the following precedence applies:
    • First precedence: command line option
    • Second precedence: environment variable
    • Third precedence: use of default value

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.
  • SCHEDULER_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.
  • SCHEDULER_HTTP_PORT
    • sets the port that the JobScheduler Agent is listening to.
    • Without setting this environment variable the port defaults to 4445.
  • SCHEDULER_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 acount 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.
  • SCHEDULER_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.
  • SCHEDULER_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 SCHEDULER_LOG_DIR environment variable or the log directory default value.

Usage Examples

Running the JobScheduler Agent on Windows

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

set JAVA_HOME=%ProgramFiles%\Java\jre8
set SCHEDULER_LOG_DIR=%ProgramData%\sos-berlin.com\agent\jobscheduler_agent_1.10-TP1\logs
 
"%ProgramFiles%\sos-berlin.com\agent\jobscheduler_agent_1.10-TP1\bin\jobscheduler_agent.cmd" start

Running the JobScheduler Agent on Mac OS X

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

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

Automated Start-up and Shutdown of JobScheduler 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 SCHEDULER_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 use of the Windows registry is recommended.
    • Consider available options from the Microsoft Technet article Understand and Control Startup Apps with the System Configuration Utility, e.g. by
      • adding the JobScheduler Agent start command to the registry key: HKLM\Software\Microsoft\Windows\CurrentVersion\Run
      • adding the JobScheduler Agent start command to the Windows Task Scheduler to be executed at startup.
    • Operating the Agent as a Windows service is currently not in scope of the Agent roadmap. 

Running multiple instances of JobScheduler Agent

  • Multiple instances of the JobScheduler Agent on the same computer can be operated, e.g. for different user accounts that jobs should be executed for.
  • 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 JobScheduler Master.
  • Running the Agent for different user accounts and ports 
    • Use the environment variable SCHEDULER_USER to operate the Agent for a user account that is different from the one that starts the Agent.
    • Use the environment variable SCHEDULER_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 SCHEDULER_LOG_DIR and SCHEDULER_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

Set log directory and port by environment variables
set JAVA_HOME=%ProgramFiles%\Java\jre8
set SCHEDULER_LOG_DIR=%ProgramData%\sos-berlin.com\agent\jobscheduler_agent_1.10-TP1\logs
set SCHEDULER_HTTP_PORT=4446
 
"%ProgramFiles%\sos-berlin.com\agent\jobscheduler_agent_1.10-TP1\bin\jobscheduler_agent.cmd" start

Examples for Unix

Switch user account and port by commands and options
su - js
jobscheduler_agent.sh start -http-port=4446
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 Agent Operability

A simple way to test if the installed and running JobScheduler 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):

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

<process_class  max_processes="10" remote_scheduler="http://localhost:4445"/>

Important! When defining the remote JobScheduler host, it is required to add http://, e.g. like above http://localhost.

 

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

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). 

Logs

The easiest way to check if the test was successful is to have a look at the job log in JOC and to see if the job completed successfully. Otherwise an error will be reported in JOC.

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

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

Remote file watching

The java based agent is compatible with JobScheduler Master versions down to release 1.6.

To use the new remote file monitoring feature, a patched JobScheduler Master is required:

  • install JobScheduler 1.9
  • download patch archive for the platform of the JobScheduler Master server
  • stop JobScheduler Master
  • extract the patch into your SCHEDULER_HOME directory
  • remove com.sos-berlin.jobscheduler.engine-1.9.jar from SCHEDULER_HOME/lib/sos

To configure remote file watching, JobScheduler Agent TP2 provides the remote_scheduler attribute for the file_order_source element:

<job_chain >
    <file_order_source remote_scheduler="http://agent_host:4445" directory="/srv/files/in"/>
    <job_chain_node state="start" job="job1"/>
</job_chain>

Currently JOE does not support setting the remote_scheduler attribute. It has to be configured in the xml jobchain definition file. When opening such a file or hot folder with JOE, there will be a warning message, but editing other attributes will still work.

The <file_order_sink> element cannot be used for job chains with remote file monitoring in TP2. To avoid blacklisting the file (re-)move it with a shell job or with File Operations JITL Jobs.

Running the remove file order example

  • Download agent_file_order.zip
  • Extract the archive into the live folder of your JobScheduler Master
  • edit files:
    • agent.process_class.xml: configure the host and port of your agent
    • job_chain1.job_chain.xml
      • configure the host and port of your agent
      • set the input directory
    • job1.job.xml
      • linux users: make adjustments to the shell script
    • job2.job.xml
      • set the output directory
      • linux users: make adjustments to the shell script

Failed Tests

In case that you receive an error in JOC when running the job, then let us know by use of the SourceForge ticket system:

  1. Create a Ticket in SourceForge
  2. Attach the following logs: scheduler.log (from JobScheduler Master) and jobscheduler_agent_<port>.log (from JobScheduler Agent)

 

 

  • No labels