AutoSys Event Server and Event Processor Explained
- The Event Server is a relational database storing all job definitions, events, global variables, and machine state.
- The Event Processor is event-driven — it re-evaluates job conditions whenever any event occurs, not on a timer.
- The eventor command starts the Event Processor on Unix/Linux; sendevent -E STOP_DEMON stops it gracefully.
Two components sit at the absolute centre of AutoSys: the Event Server and the Event Processor. Everything else in the system — agents, clients, the GUI — exists to feed data into or read data out of these two. Understanding how they work together, and what can go wrong with each, is the foundation of being effective with AutoSys in production.
Inside the Event Server
The Event Server is a relational database with several key tables. The job definition tables store all JIL attributes — job name, type, command, machine, scheduling parameters, conditions, and so on. The event tables store a timestamped log of every event that has occurred — job_started, job_success, job_failure, sendevent calls, etc. The global variable table stores name/value pairs that jobs can read and write. The machine table stores the list of registered agents and their current status.
When AutoSys starts up or restarts, the Event Processor rebuilds its in-memory state by reading the Event Server. This is why if you add a new job via JIL while AutoSys is running, it's immediately available — it's in the database.
# Check if Event Server is reachable autoping -S ACE # Check AutoSys system status including event server chk_auto_up # View the AutoSys instance and event server info autoflags -a
Event Server: prod-db-server/autosys_db
Status: UP
Event Processor: RUNNING
Last heartbeat: 03/19/2026 14:32:10
How the Event Processor evaluates job conditions
The Event Processor runs in a continuous loop. On each iteration, it scans for events that have occurred since its last scan and determines which jobs might be affected. For each potentially affected job, it evaluates the job's starting conditions.
A job's starting conditions can include: a time condition (it's past the start_time and the days_of_week match), a success condition on another job (success(job_a)), a failure condition (failure(job_b)), a notrunning condition, or a combination with AND/OR logic. When all conditions evaluate to true and the job is not ON_HOLD or ON_ICE, the Event Processor fires the job to the appropriate agent.
/* Job that runs only after two others succeed */ insert_job: final_report job_type: CMD command: /opt/scripts/final_report.sh machine: prod-server-01 owner: svcaccount condition: success(extract_job) AND success(transform_job) /* Job with time AND dependency condition */ insert_job: morning_summary job_type: CMD command: /opt/scripts/summary.sh machine: prod-server-01 owner: svcaccount days_of_week: mo,tu,we,th,fr start_times: "08:00" condition: success(overnight_batch)
Event Processor startup and the eventor command
On Unix/Linux, the Event Processor is started with the eventor command. It runs as a background daemon and writes log output to $AUTOUSER/out/event_demon.$AUTOSERV. The first thing it does on startup is check that no other Event Processor is running for the same instance — if one is, it exits immediately.
On startup, it also performs a recovery scan: it checks for any jobs that were running when it last shut down and updates their status appropriately. This is the recovery mechanism that prevents jobs from getting stuck in RUNNING status after an Event Processor restart.
# Start the Event Processor eventor # Stop the Event Processor gracefully sendevent -E STOP_DEMON # View the event processor log astail -f $AUTOUSER/out/event_demon.ACE # Check event processor is running autoping
Instance: ACE
Event Server: prod-db-server
Dual Event Server for high availability
For production environments that can't afford downtime, AutoSys supports a primary/shadow Event Server configuration. The primary Event Server handles all activity normally. The shadow Event Server is an always-current replica. If the primary fails, AutoSys automatically fails over to the shadow with no loss of job state.
A tie-breaker scheduler is used in dual-server setups to resolve conflicts and determine which server should be the primary after a failover. This is configured at installation time and is largely transparent to day-to-day operations.
| Aspect | Event Server | Event Processor |
|---|---|---|
| What it is | Relational database (Sybase/Oracle) | Background daemon process |
| What it stores | Job defs, events, state, globals | Nothing — reads from Event Server |
| Started with | Database startup | eventor command |
| Stopped with | Database shutdown | sendevent -E STOP_DEMON |
| How many per instance | 1 primary + optional shadow | Exactly 1 |
| Log location | Database tables | $AUTOUSER/out/event_demon.$AUTOSERV |
| Failure impact | All AutoSys stops | No new jobs triggered |
🎯 Key Takeaways
- The Event Server is a relational database storing all job definitions, events, global variables, and machine state.
- The Event Processor is event-driven — it re-evaluates job conditions whenever any event occurs, not on a timer.
- The eventor command starts the Event Processor on Unix/Linux; sendevent -E STOP_DEMON stops it gracefully.
- AutoSys supports primary/shadow Event Server for high availability — failover is automatic.
- The event_demon log is your first stop when debugging unexpected job behaviour.
⚠ Common Mistakes to Avoid
- ✕Starting the Event Processor before the Event Server is ready — this causes startup errors and an incomplete state recovery.
- ✕Letting event history grow without purging — the events table can grow very large over months and slow down Event Processor scanning.
- ✕Not checking the event_demon log when jobs behave unexpectedly — the log shows exactly why conditions did or did not evaluate to true.
- ✕Using kill -9 on the Event Processor, which leaves stale RUNNING statuses in the Event Server that need manual correction.
Interview Questions on This Topic
- QWhat is stored in the AutoSys Event Server?
- QHow does the Event Processor evaluate job starting conditions?
- QWhat command starts the Event Processor and what does it do on startup?
- QHow does AutoSys achieve Event Server high availability?
- QWhat happens if you kill the Event Processor with kill -9?
Frequently Asked Questions
How often does the Event Processor scan for jobs to run?
The Event Processor is event-driven, not timer-driven. It re-evaluates job conditions every time an event occurs (a job changes status, a sendevent is called, a time trigger fires, etc.). This makes triggering near-real-time rather than polling on a fixed interval.
Can AutoSys run without a shadow Event Server?
Yes, many environments run with just a primary Event Server. The shadow is optional and adds complexity. It's recommended for mission-critical environments where scheduling downtime is unacceptable, but smaller teams often skip it.
What is the event_demon log and where do I find it?
The event_demon log captures Event Processor activity — condition evaluations, job triggers, errors, and system messages. It's located at $AUTOUSER/out/event_demon.$AUTOSERV on the AutoSys server. It's the most useful diagnostic file when jobs aren't behaving as expected.
What is the $AUTOSERV variable?
$AUTOSERV is an environment variable that holds the three-character identifier for the AutoSys instance (e.g. ACE, PRD, DEV). It's used throughout AutoSys commands and file paths to distinguish between multiple instances running on the same server.
Developer and founder of TheCodeForge. I built this site because I was tired of tutorials that explain what to type without explaining why it works. Every article here is written to make concepts actually click.