Command-Line Job Scheduler

Overview

A lightweight, modular command-line job scheduler written in C++17. The system executes one-time and recurring jobs with deterministic timing, persists job state to disk, and cleanly separates scheduling, execution, and storage responsibilities.
The projext is intentionally scoped to demonstrate systems thinking, correctness and debuggability rather than feature sprawl.

Why This Exists

Many student schedulers only work while the process is alive. This project goes one step furhter by:

• Persisting jobs to disk
• Reloading state on restart
• Preventing time drift in recurring tasks
  This represents the minimum baseline for a scheduler that behaves predictably in real environments.

Key Features

• One-time & recurring jobs (interval-based)
• No time drift for recurring execution
• Persistent storage (data/jobs.txt)
• Explixit filesystem handling (deterministic paths)
• Modular architecture (Scheduler / Executor / JobStore)
• Command execution via system calls

Architecture

main.cpp
  └── Scheduler
    ├── JobStore (persistence)
    ├── Executor (command execution)
    └── Time logic (sleep + scheduling)

Components

1. Scheduler

• Owns job lifecycle and timing loop
• Adds jobs, schedules execution, reschedules recurring jobs

2. JobStore

• Loads jobs on startup
• Saves jobs on state change
• Manages filesystem paths (data/ directory)

3. Executor

• Executes shell/system commands
• Isolated from scheduling logic

Persistence Model

• Jobs are serialized to data/jobs.txt
• Format:

id|run_at|recurring|interval|command

• File is flushed and closed explicitly to avoid buffering issues in long-running processes

Time Handling

• Uses std::chrono for all timing
• Recurring jobs are rescheduled based on planned next run, not actual execution time
• Prevents cumulative delay (time drift)

Build & Run (Windows)

Requirements

• MinGW-w64
• g++ (C++17)

Compile

g++ -std=c++17 main.cpp scheduler.cpp executor.cpp job_store.cpp -o taskd.exe

Run

.\taskd.exe 

Known Limitations

• No CLI argument parsing (intentional)
• No concurrency (single-threaded loop)
• No networking or remote control

These are design choices to keep scope tight and correctness high.

What I'd Add Next (If Required)

• Graceful shutdown + reload-on-start
• --list CLI command
• Structured logging with timestamps

Learning Outcomes

• Designing and wiring modular C++ systems
• Correct use of filesystem APIs and deterministic paths
• Understanding working directory vs source directory behavior
• Debugging long-running processes with explicit logging
• Avoiding time drift using std::chrono