Proposal: Workspace-level cron persistence via /home/devuser/workspace/cron.txt

[tryweb]

Problem

In ai-engkit container environment, cron daemon is not installed and crontab entries do not persist across container restarts/recreation. Each project under /home/devuser/workspace/ that needs periodic tasks (e.g. LibreNMS alert polling every 5 min) must currently be set up manually after every container restart.

The workspace root contains multiple project directories (17+ in typical deployment), each with different cron requirements.

Proposed Solution

Introduce two mechanisms:

1. Workspace-level cron.txt at /home/devuser/workspace/cron.txt

A plain-text file as the single source of truth for cron definitions, shared across all projects. Format:

# project:ichiayi-it
*/5 * * * * /home/devuser/workspace/ichiayi-it/scripts/librenms/check_alerts.sh >> /home/devuser/workspace/ichiayi-it/data/librenms/check.log 2>&1

# project:ai-km
0 3 * * * /home/devuser/workspace/ai-km/scripts/cleanup.sh

Key design decisions:

• Full replace sync — on container start, the crontab is cleared and rewritten entirely from cron.txt. This prevents stale entries when a line is removed from cron.txt.
• Project label convention — # project:<name> comment lines for ownership tracking
• Bound to workspace — /home/devuser/workspace/ is a host bind mount (ext4), survives container recreation

2. Entrypoint script at /entrypoint.d/07-setup-cron.sh

Injected via volume mount in the container orchestration config:

volumes:
  - ./scripts/setup-cron.sh:/entrypoint.d/07-setup-cron.sh

This script runs on every container start:

• Install cron daemon if missing (apt-get)
• Read /home/devuser/workspace/cron.txt
• Write entries to crontab (full replace)
• Start cron daemon

Alternative Considered

Per-project .crontab files (e.g. /home/devuser/workspace/*/.crontab) were considered for better isolation, but a single cron.txt was chosen for simplicity and centralized auditability.

Open Questions

1. Should cron.txt be git-tracked in ai-engkit repo or gitignored (environment-specific)?
2. Basic validation in the setup script — reject lines with non-existent command paths?
3. Should we support cron.d directory style (drop-in files) as an alternative?

Expected Outcome

• Cron jobs survive docker compose down/up
• Any project can add periodic tasks by editing one file
• No manual per-container setup after restart