Command Runners (Agents)
Linux Agent Installation Guide
This document shows how to install and manage the Linux agent for Unmeshed Job Scheduling Platform. The agent is a Java-based application which runs natively on Linux machines and executes the scheduled jobs as configured on the Unmeshed Platform. The integration between agent and Unmeshed platform is protected by an access key and secret and happens over an HTTPS connection.
Prerequisites
Unmeshed CLI
To add an agent, we require the installation of Unmeshed CLI. You can find the guide here.
Installation
Run the following commands and follow the prompts to complete the agent installation. It will download the required files automatically and place them in your selected folder.0
To uninstall the agent, you can use the CLI
The CLI has other commands that can list agents installed in the host. You'd only need a single agent installation typically, but if you need to install multiple agents for any reason, the CLI supports this in its prompts.
Configuration
Step 1: Configure the Agent Worker
Go to the installation folder for your agent. Edit the processes.yaml file to configure your agent:
The file should contain the following configuration:
Configuration Parameters
| Field | Description |
|---|---|
UNMESHED_AUTH_ID | This is a generated field from the Unmeshed Platform when you create a client application |
UNMESHED_AUTH_TOKEN | This is a generated field from the Unmeshed Platform when you create a client application |
UNMESHED_ENGINE_URL | HTTPS URL for the Unmeshed server the agent should connect to |
UNMESHED_BASH_CUSTOM_WORKERS | Advanced Configuration: Comma-separated list of custom worker specifications in the format namespace:name:maxConcurrentWorkers:falseExample: default:custom-bash:50,prod:high-priority:100Format: Each specification contains 3 parts separated by colons: - namespace: The namespace for this worker (e.g., "default", "prod")- name: The worker name identifier- maxConcurrentWorkers: Maximum number of concurrent jobs this worker can handleDefault Behavior: If left empty, the agent registers a default bash worker under the "default" namespace with the name "bash" |
UNMESHED_BASH_MAX_CONCURRENT_WORKERS | Maximum number of concurrent bash commands that can be executed simultaneously |
UNMESHED_ENGINE_EMAIL_ENABLED | Enable/disable email sender worker |
UNMESHED_EMAIL_SMTP_HOST | SMTP server hostname for sending email |
UNMESHED_EMAIL_SMTP_PORT | SMTP server port (usually 25, 465, or 587) |
UNMESHED_EMAIL_SMTP_USER | SMTP server username for authentication |
UNMESHED_EMAIL_SMTP_PASSWORD | SMTP server password for authentication |
UNMESHED_WORK_RESPONSE_BATCH_SIZE | Number of work responses to batch together before sending to the server |
UNMESHED_BASH_CUSTOM_WORKERS Configuration
The UNMESHED_BASH_CUSTOM_WORKERS parameter allows you to create multiple custom bash workers with different configurations. This is useful when you need different concurrency limits or want to separate workloads by namespace.
For Linux agents, the ioThread parameter must always be set to false.
Format
Each worker specification follows the format: namespace:name:maxConcurrentWorkers:false
- namespace: The namespace for this worker (e.g., "default", "prod", "dev")
- name: The worker name identifier that will be used in job definitions
- maxConcurrentWorkers: Maximum number of concurrent jobs this worker can handle
- ioThread: Must be set to
falsefor Linux agents (required parameter)
Examples
Single Custom Worker:
This configuration will query for jobs in the prod namespace with the name high-priority-bash and can run up to 100 concurrent tasks.
Multiple Custom Workers:
This configuration creates three workers:
default:bash.servername.standard:50:false- Namespacedefault, jobs namedstandard-bash, concurrency of 50prod:bash.servername.priority:100:false- Namespaceprod, jobs namedhigh-priority-bash, concurrency of 100dev:bash.servername.testing:25:false- Namespacedev, jobs namedtesting-bash, concurrency of 25
Since your agents can run in any server, using the server name in the bash worker name is a good way to distinctly identify the agent running on this host and you can assign tasks by this name to run on this host.
No Custom Workers (Default):
Verification
Check Agent Logs
The agent creates logs in the working directory. Look for the following log entry to confirm successful startup:
You should see a log entry similar to:
Check Service Status
Operating the Unmeshed Agent
Service Management Commands
Troubleshooting
Common Issues
-
Service fails to start:
- Check file permissions:
ls -la <directory name used in installation> - Verify Java installation:
java -version - Check service logs:
sudo journalctl -u <service name used in installation> -n 50
- Check file permissions:
-
Agent cannot connect to Unmeshed platform:
- Verify network connectivity:
ping <your-unmeshed-server> - Check authentication credentials in
processes.yaml - Verify firewall settings
- Verify network connectivity:
-
Permission denied errors:
- Ensure the service user owns the
<directory used in installation>directory - Check file permissions:
chmod +x <directory used in installation>/start_monitor.sh
- Ensure the service user owns the
-
Java memory issues:
- Adjust JVM memory settings in
processes.yaml:-Xms1024m(minimum heap size)-Xmx1024m(maximum heap size)
- Adjust JVM memory settings in
Log Analysis
The agent creates several log files:
- worker.log - Main worker process logs
- monitor.log - Monitor process logs
- systemd logs - Service management logs
Security Considerations
- File Permissions: Ensure only authorized users can access the agent configuration files
- Network Security: Use HTTPS connections to the Unmeshed platform
- Authentication: Keep your auth ID and token secure and rotate them regularly
- Service User: Run the service with minimal required privileges
- Firewall: Configure firewall rules to allow only necessary outbound connections
Concurrency Settings
Adjust based on your system's CPU cores and workload:
Batch Processing
Optimize network communication:
FAQs & Notes
- Service Auto-restart: The systemd service is configured to automatically restart if the process crashes
- Log Rotation: Consider implementing log rotation for long-running deployments
- Monitoring: Set up monitoring for the service status and resource usage
- Backup: Regularly backup your
processes.yamlconfiguration file - Updates: Keep your Linux system updated for security patches
- Resource Monitoring: Monitor CPU, memory, and disk usage during operation