Scheduled Events

A built-in cron replacement. Sysop-only, Admin → Scheduled Events
(/admin/events/). Maintenance jobs run inside the same process as
the web app, on a one-minute tick, with results visible right in the
admin UI — no need to grep syslog to find out if last night's VACUUM
actually ran.

How it works

A background thread wakes every 60 seconds, loads every row with
Enabled checked, and fires any whose schedule says it's due. Each
row records last_run_at, last_status (ok/fail),
last_duration_ms, and the first 4KB of captured output — all shown
in the admin list. Editing or disabling a row takes effect on the
next tick (within a minute); no restart needed.

There's no per-event timeout enforced by the scheduler itself — a
handler that hangs blocks the next tick's events. Handlers that shell
out to something that could run long (like shell, below) enforce
their own timeout instead.

Creating an event

• Name — free text, shown in the admin list only.
• Handler — picks the built-in function that runs (see table
  below). Each option shows its description and expected params once
  selected.
• Schedule — one of four kinds:
• Daily — pick a time (HH:MM, UTC).
• Hourly — pick a minute-of-hour (0–59).
• Weekly — pick a day (Mon–Sun) + time, UTC.
• Every N min ("interval") — repeats N minutes after the
  previous run finished, not wall-clock-aligned.
• Params (JSON object) — handler-specific arguments. Must parse
  as a JSON object, even if empty ({}) — a bare string or path is
  rejected. A handler taking one argument called command wants
  {"command": "/path/to/script.sh"}, not just the path.
• Enabled — unchecked rows never fire but stay in the list.

There's also a Run now button per row for testing without waiting
on the schedule — same code path either way, so output shown after a
manual run matches exactly what a scheduled fire would produce.

All schedule times are UTC, not the server's local timezone or
any caller's timezone — keep that in mind when picking a "quiet
hours" slot.

Built-in handlers

The three sync_*_inbound handlers aren't something you'd pick from a
blank slate — they appear already-created and enabled the moment you
turn on the matching InterBBS feature (Wall, Last Callers, or Game
Score sharing) on a network. Listed here so they aren't a mystery if
you spot one.

shell handler — worked example

Running a nightly TradeWars external-events script via dosemu2:

Params (JSON object):

{"command": "/opt/anetbbs/doors/dos/tw/event.sh", "timeout": 120}

event.sh:

#!/bin/bash
export TERM=linux
cd /opt/anetbbs/doors/dos/tw
/usr/libexec/dosemu2/dosemu2.bin -td EXTERN.EXE

export TERM=linux and -td (dumb-terminal mode) are required
because the scheduler runs the command with no controlling tty — a
normal door launch gets a real PTY from door_runner.py, but a
scheduled shell command doesn't. Without these, dosemu2 fails with
ERROR: TERM environment variable needs set. before it ever reaches
your DOS program.

Default events on a fresh install

Seeded once (idempotent — re-running the seeder skips handler keys
that already have a row):

Any of these can be disabled, deleted, or rescheduled — they're
normal rows, not special-cased.

On installs with REGISTRY_MODE_ENABLED=true (the designated
ANotherNetwork hub), a fifth event is also seeded:

This one is skipped on regular (non-hub) installs — there's nothing
useful for it to publish there.

Troubleshooting

• "Params (JSON object)" rejects what I typed — it must parse as
  a JSON object. /path/to/script.sh isn't valid JSON; wrap it as
  {"command": "/path/to/script.sh"}.
• dosemu2 commands fail with TERM environment variable needs set — see the worked example above; export TERM and pass
  -td in your script.
• An event always fails the same way — click Run now and
  read the captured output; it's the same stdout/stderr you'd get
  running the command by hand over SSH, just minus your interactive
  shell's environment (PATH, TERM, etc. may differ — set them
  explicitly in the script if needed).

See also

• Sysop Control Panel
• Sysop Guide
• Backup