Students often confuse tasks with services because both can execute without direct user interaction.
The key difference is their execution model.
| Characteristic | Service | Automated Task |
|---|---|---|
| Purpose | Provide ongoing functionality | Perform a specific action |
| Execution | Runs continuously | Runs when triggered |
| Lifetime | Usually long-running | Usually short-lived |
| Examples | Nginx, MySQL, SSH | Backups, Updates, Log Cleanup |
| Typical Behavior | Start → Run → Wait | Start → Perform Work → Exit |
Examples:
Nginx
↓
Runs continuously
↓
Waits for requests
This is a service.
02:00 Every Day
↓
Run backup.sh
↓
Backup completes
↓
Exit
This is a task.
Services are typically always running.
Automated tasks typically execute, complete their objective, and terminate.
Both are important, but they solve different problems within the operating system.
Why This Matters
Automated execution appears throughout modern environments.
Examples:
- Backups
- Log Rotation
- Updates
- Monitoring
- Security Scans
- Custom Scripts
Attackers also frequently abuse automated execution mechanisms for persistence.
Automated Execution
Automated execution answers a simple question:
How can a program run without a user manually launching it?
Linux commonly solves this through:
- Cron
- Crontab
- systemd Timers
These mechanisms allow tasks to execute automatically based on time.
Cron
Historically, Linux systems used:
cron
as the primary scheduling service.
Cron runs continuously in the background and checks whether scheduled tasks should execute.
When a scheduled time arrives, cron launches the configured command.
What Is a Cron Job?
A cron job is a scheduled task managed by cron.
Examples:
- Run every day
- Run every hour
- Run every week
- Run every month
Example:
Every day at 02:00
↓
Run backup.sh
The user does not need to be logged in.
Cron executes the task automatically.
Crontab
Scheduled cron jobs are commonly stored within:
crontab
A crontab defines:
- When a task runs
- What command executes
Example:
0 2 * * * /opt/scripts/backup.sh
Conceptually:
Time
↓
Command
Cron Schedule Structure
Cron schedules are composed of five time fields.
Example:
0 2 * * * /opt/scripts/backup.sh
| Field | Meaning |
|---|---|
| Minute | 0 |
| Hour | 2 |
| Day of Month | * |
| Month | * |
| Day of Week | * |
Result:
Run every day at 02:00
Common Cron Examples
Every hour:
0 * * * * command
Every day at midnight:
0 0 * * * command
Every Sunday:
0 0 * * 0 command
These examples illustrate scheduling concepts.
Operators are not expected to memorize every cron pattern.
Where Cron Jobs Are Stored
Common locations include:
/etc/crontab
/etc/cron.d/
/etc/cron.hourly/
/etc/cron.daily/
/etc/cron.weekly/
/etc/cron.monthly/
Users may also maintain personal crontabs.
User Crontabs
Individual users can possess their own scheduled tasks.
Examples:
alice
peter
root
Each user may schedule commands that execute under their own security context.
This becomes important during investigations and privilege escalation.
Why Cron Matters To Operators
Questions Operators commonly ask:
- What executes automatically?
- Who configured it?
- Under which user does it run?
- Has it been modified?
Many persistence mechanisms leverage cron.
Examples:
Every minute
↓
Download malware
System Startup
↓
Launch payload
systemd Timers
Modern Linux distributions increasingly use:
systemd timers
alongside traditional cron jobs.
Timers integrate with:
systemd
which was introduced in the previous lesson.
Conceptually:
Timer
↓
Triggers
↓
Service
Why Timers Exist
Timers provide functionality that cron lacks.
Examples:
- Better dependency management
- Improved logging
- Easier service integration
- More flexible scheduling
As a result, many modern distributions favor timers for new deployments.
Timer Example
Conceptually:
Every day at 02:00
↓
backup.timer
↓
backup.service
↓
backup script executes
The timer controls when execution occurs.
The service defines what executes.
Cron vs Timers
| Feature | Cron | systemd Timer |
|---|---|---|
| Traditional | Yes | Modern |
| Integrated with systemd | No | Yes |
| Service Awareness | Limited | Yes |
| Logging Integration | Limited | Better |
| Commonly Encountered | Very Common | Increasingly Common |
Operators should be familiar with both mechanisms.
Security Implications
Automated tasks can introduce security risks.
Examples:
- Running scripts as root
- Executing writable files
- Downloading content automatically
- Launching untrusted software
Questions Operators commonly ask:
- Does the task run as root?
- Can the executed file be modified?
- Is the configuration trusted?
- Is this expected behavior?
Misconfigured scheduled tasks frequently appear in privilege escalation scenarios.
Investigative Perspective
During investigations, automated tasks often answer important questions.
Examples:
| Question | Investigation Value |
|---|---|
| What runs automatically? | Persistence |
| Who created the task? | Attribution |
| When does it execute? | Timeline |
| What command executes? | Impact |
| Does it contact external systems? | Threat Activity |
Automated execution mechanisms are commonly reviewed during incident response.
Operator Perspective
When approaching an unfamiliar Linux system, Operators commonly ask:
Cron
- Are cron jobs configured?
- Who owns them?
- What commands execute?
- When do they execute?
Timers
- Which timers exist?
- Which services do they trigger?
Security
- Do any tasks run as root?
- Can executed files be modified?
Investigations
- Was a scheduled task added recently?
- Is it legitimate?
- Does it provide persistence?
Understanding automated tasks frequently reveals both operational behavior and attacker activity.
Key Takeaways
- Linux supports automated task execution.
- Cron is the traditional scheduling mechanism.
- Cron jobs are configured through crontabs.
- Tasks execute according to defined schedules.
- Users may maintain their own scheduled tasks.
- Modern Linux systems increasingly use systemd timers.
- Timers trigger services managed by systemd.
- Automated tasks are commonly used for administration.
- Automated tasks are frequently abused for persistence.
- Scheduled execution mechanisms are important during investigations, privilege escalation, and incident response.
The next lesson explores telemetry and how Linux records activity occurring on a system.