Stop order: scheduler → application server → agents → database.
The scheduler goes last on start, so the database and agents it needs are already up; first on stop, so no new jobs launch mid-shutdown.
Unix services: unisrvcntr stop|start|status waae_sched.$AUTOSERV and waae_server.$AUTOSERV. Agents: ./cybAgent -s (stop), ./cybAgent -a (start).
Before stopping: autorep -J ALL | grep ' RU ' to see running jobs. Before starting the scheduler: autoping -m ALL. After: chk_auto_up.
✦ Definition~90s read
What is AutoSys Start and Stop Order?
AutoSys Workload Automation has four parts that depend on each other: the event server (database), the agents that run jobs, the application server that serves commands and the web UI, and the scheduler (event_demon) that decides what runs. Start them bottom up with the scheduler last, and stop them top down with the scheduler first.
★
Think of opening a restaurant.
Plain-English First
Think of opening a restaurant. The pantry (database) has to be stocked and the cooks (agents) in the kitchen before the head chef (scheduler) starts sending orders. At closing time the chef stops taking orders first, the cooks finish what's on the stove, and the pantry is locked last.
After a patch weekend every server was up, but 312 jobs sat in PEND_MACH at 06:00. Nothing was broken: the scheduler had simply been started before the agents. AutoSys components depend on each other, so the order you start and stop them matters. This guide gives the order, the commands and the checks.
The Four Components
The event server is the database that holds every job definition and event. Agents run on each target machine and execute jobs. The application server handles requests from the command-line tools and the web UI. The scheduler (event_demon) reads events from the database and sends jobs to agents. Each depends on the one before it.
status.shBASH
1
2
3
unisrvcntr status waae_sched.$AUTOSERV
unisrvcntr status waae_server.$AUTOSERV
chk_auto_up
🔥Names vary
Service names and paths depend on your version and install. Check your install's service list before scripting it.
🎯 Key Takeaway
Database, agents, application server, scheduler: each needs the one before.
Start Order
Start the database first, then the agents, then the application server, then the scheduler. The scheduler goes last so that when it begins evaluating jobs, the database it reads and the agents it sends to are already there. Ping every agent before the scheduler starts.
start.shBASH
1
2
3
4
5
6
7
8
# 1. database (event server): start per your DBA's procedure
# 2. agents, on each host
cd $AGENT_HOME && ./cybAgent -a
# 3. check every agent answers
autoping -m ALL
# 4. application server, then scheduler
unisrvcntr start waae_server.$AUTOSERV
unisrvcntr start waae_sched.$AUTOSERV
🎯 Key Takeaway
Start bottom up: the scheduler goes last.
Stop Order
Stop the scheduler first so no new jobs start. Let running jobs finish (or decide to restart them later). Then stop the application server, the agents and the database last.
stop.shBASH
1
2
3
4
5
unisrvcntr stop waae_sched.$AUTOSERV
autorep -J ALL | grep ' RU ' # wait until empty
unisrvcntr stop waae_server.$AUTOSERV
cd $AGENT_HOME && ./cybAgent -s
# database last
⚠ Stopping an agent stops its jobs
Jobs running on an agent you stop won't finish. Check RU jobs first.
🎯 Key Takeaway
Stop top down: the scheduler goes first.
What Goes Wrong in the Wrong Order
Scheduler before agents: jobs go to PEND_MACH. Scheduler before the database: the scheduler can't read events and won't run. Agents stopped before the scheduler: jobs it launches in the meantime can't start. Database stopped under a running scheduler: the scheduler loses its event source.
after_late_agent.shBASH
1
2
# Agents came up late? check the PE jobs moved on
autorep -J ALL | grep ' PE '
🎯 Key Takeaway
Most start/stop incidents are the scheduler running without something it needs.
● Production incidentPOST-MORTEMseverity: high
The Patch Weekend That Left 312 Jobs in PEND_MACH
Symptom
At 06:00 on Sunday, 312 jobs went to PEND_MACH. The scheduler and database were running. Agent hosts were still rebooting.
Assumption
The team assumed a network problem between the scheduler and the agents.
Root cause
The scheduler was started before the agents. Jobs due at 06:00 were sent to machines whose agents weren't running yet, so the scheduler marked them PEND_MACH.
Fix
Started the agents, checked them with autoping -m ALL, then confirmed every PE job started. Wrote the start order into the patching runbook and made the scheduler start the last step.
Key lesson
The scheduler starts last and stops first.
Ping every agent before starting the scheduler.
After a late agent start, check that every PEND_MACH job actually ran.
Production debug guideChecks before and after each step4 entries
Symptom · 01
About to stop AutoSys
→
Fix
autorep -J ALL | grep ' RU ' to list running jobs; let them finish or plan a restart.
Symptom · 02
Scheduler won't stay up after start
→
Fix
Check the database is up and reachable first; the scheduler needs the event server.
Symptom · 03
Jobs go PEND_MACH right after start
→
Fix
Agents weren't up. autoping -m ALL, start the missing agents.
Symptom · 04
Not sure what's running
→
Fix
unisrvcntr status waae_sched.$AUTOSERV and waae_server.$AUTOSERV; chk_auto_up for the overall state.
⚙ Quick Reference
4 commands from this guide
File
Command / Code
Purpose
status.sh
unisrvcntr status waae_sched.$AUTOSERV
The Four Components
start.sh
cd $AGENT_HOME && ./cybAgent -a
Start Order
stop.sh
unisrvcntr stop waae_sched.$AUTOSERV
Stop Order
after_late_agent.sh
autorep -J ALL | grep ' PE '
What Goes Wrong in the Wrong Order
Key takeaways
1
Start
database → agents → application server → scheduler.
2
Stop
scheduler → application server → agents → database.
3
autoping -m ALL before the scheduler starts.
4
Check RU jobs before stopping agents.
Common mistakes to avoid
3 patterns
×
Starting the scheduler first
Symptom
Jobs in PEND_MACH right after start.
Fix
Start agents first and autoping them.
×
Stopping agents with jobs running
Symptom
Jobs killed mid-run.
Fix
Check autorep for RU jobs before stopping.
×
Rebooting the database under a live scheduler
Symptom
Scheduler stops processing events.
Fix
Stop the scheduler before database maintenance.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01JUNIOR
In what order do you start AutoSys components?
Q02SENIOR
Why stop the scheduler first?
Q01 of 02JUNIOR
In what order do you start AutoSys components?
ANSWER
Database (event server), agents, application server, then the scheduler last.
Q02 of 02SENIOR
Why stop the scheduler first?
ANSWER
So no new jobs are launched while the other components go down.
01
In what order do you start AutoSys components?
JUNIOR
02
Why stop the scheduler first?
SENIOR
FAQ · 3 QUESTIONS
Frequently Asked Questions
01
What is the correct start order for AutoSys?
Database, agents, application server, then the scheduler last.
Was this helpful?
02
How do I stop the AutoSys scheduler?
On Unix: unisrvcntr stop waae_sched.$AUTOSERV. sendevent -E STOP_DEMON also stops it.
Was this helpful?
03
Why are my jobs in PEND_MACH after a restart?
The scheduler started before the agents. Start the agents and check with autoping.