Updating Platform Agents

When the RunMyJobs server is updated to a new version, its Platform Agents must also be upgraded. RunMyJobs tries to make this as painless as possible. Platform Agents can even update themselves if certain conditions are met.

The first time you run an updated version of the central RunMyJobs server, it updates the database and other parts of the central system. Next, it tries to start the Platform Agents that are marked as having automatic start. As part of the startup procedure, the server sends a configuration request to the Platform Agent, telling it which Process Server parameters to use. As part of this command, it also sends its own version ID. If the Platform Agent's version ID does not match, it sends a result indicating that the configuration failed. It also tells the RunMyJobs server whether it has the required version installed (but not active for this instance) and whether it is able to restart other versions.

If the RunMyJobs server finds that the Platform Agent is able to restart but does not have the same version installed, it then sends a new Platform Agent installer to the Platform Agent. The Platform Agent stores the installer in the file system and then runs it in non-interactive mode. The installer installs the new Platform Agent side-by-side with the existing Platform Agent.

Once the new Platform Agent is successfully installed (or if the new version was already installed, but not active), RunMyJobs sends a restart request to the Platform Agent. The Platform Agent activates the new version, then the old Platform Agent stops and the new Platform Agent starts. How this is accomplished depends on the platform.

  • On Windows, the Platform Agent must be started using a service as NT Authority\System.
  • On UNIX, the Platform Agent must be started using the ${InstallDir}/<version>/bin/platform-agent shell script, in combination with the native init system.
  • On OpenVMS, the Platform Agent must be started using SCHEDULER.COM.

Note: The Platform Agent makes sure there is sufficient disk space available prior to attempting the update.

UNIX

For UNIX systems, the most important requirement is that the Platform Agent is started by means of the ${InstallDir}/<version>/bin/platform-agent shell script. If this is done, the Platform Agent can update itself.

The administrator can control whether auto-update is performed by creating or removing the ${InstallDir}/etc/startup/${Instance}/autoupdate directory. This is where the auto-update process will store the downloaded installer for the new version. If this directory does not exist, the auto-update procedure is disabled. This directory is created by the installer if you indicate that you want to allow auto-update. If you did not indicate that you want auto-update, you can enable auto-update by creating this directory manually. Make sure the privileges are such that the network-processor process can write to that directory.

Windows

On Windows, make sure the Platform Agent runs as a service running as the LocalSystem account. Only this account is able to run the installer. This is easy to do during the initial installation of the Platform Agent. Just make sure the Auto update check box is checked during installation.

OpenVMS

On systems where no relink is needed (usually 8.x OpenVMS systems), auto-update is supported. The COM files required are:

Copy 
[.2023.2.0-20230727_11.etc]SCHEDULER.COM
[.2023.2.0-20230727_11.bin]PLATFORM-AGENT.COM

Instead of the RUN command, starts should be done using the SCHEDULER.COM file.

Multiple instances per tree are installed. Separate trees (installation directories) should not use the same instance names.

How it Works: UNIX

When a Platform Agent is configured as version X, and version Y is requested by the server, the network processor first writes the correct version to the ${InstallDir}/etc/startup/${Instance}/version file. Then it stops using a special exit code. The platform-agent script recognizes this and immediately restarts the new version of the platform-agent process.

To make sure this works properly, run the Platform Agent via the platform-agent script directly or via the boot scheduler script (recommended).

How it Works: Windows

On Windows, the Platform Agent downloads and unpacks the installer. Next, it stops its own service and starts the service of the new Platform Agent by calling the Scheduler Service Manager and then waiting for a stop command. If the service manager succeeds in creating the new service, it stops the old service and then starts the new service. If it fails, the old service continues running.

Note: The Windows Platform Agent installer is not signed, but the Platform Agent binaries it contains are signed. The Platform Agent checks the integrity of the downloaded file against a hash, and if it passes, it unpacks it. (The installer is NOT executed during auto-upgrades, but merely unpacked.) The signed applications therein are then used to perform the service installation.

How it Works: OpenVMS

For more information, see Starting a Platform Agent on OpenVMS.