DB-유

Synology Task Scheduler: Scheduled Tasks and Scripts

· synology, scripting, automation

I edited /etc/crontab over SSH exactly once. It worked until the next DSM update quietly overwrote it. The supported way to run things on a schedule, at boot or at shutdown is Control Panel → Task Scheduler: a thin front end over cron that handles the user context, mails you the output, and survives upgrades. On DSM 6.2 I use it for database dumps, Docker housekeeping, rsync jobs and eject-after-backup routines.

A scheduled script

Control Panel → Task Scheduler → Create → Scheduled Task → User-defined script.

General
  Task:      docker-prune
  User:      root
  Enabled:   yes
Schedule
  Run on the following days: Daily
  First run time: 03:30
  Frequency: once a day
Task Settings
  Send run details by email: yes, to admin@example.com
  Send run details only when the script terminates abnormally: yes

And the script:

#!/bin/bash
set -e
/usr/local/bin/docker image prune -f
/usr/local/bin/docker container prune -f --filter "until=168h"

The user matters: root for anything touching Docker or system paths, a normal user for jobs that only write to shares. The environment in Task Scheduler is minimal, so use absolute paths for binaries; docker lives in /usr/local/bin, most Synology tools in /usr/syno/bin or /usr/syno/sbin.

Log to a file

The email only shows the output. For anything I might have to debug later I log to a file inside a share:

#!/bin/bash
LOG=/volume1/scripts/logs/rsync-photo-$(date +%F).log
exec >>"$LOG" 2>&1
echo "=== start $(date) ==="
rsync -av --delete /volume1/photo/ /volumeUSB1/usbshare/photo/
echo "=== end $(date) rc=$? ==="
find /volume1/scripts/logs -name 'rsync-photo-*.log' -mtime +30 -delete

Task Scheduler also has its own output store: tick Settings → Save output results → choose a folder, and every run's stdout and stderr are kept there, viewable via Action → View Result.

Keep scripts in a share, not in the GUI

Long scripts in the task's text box are hard to edit and impossible to version. I keep them under /volume1/scripts/ and make the task a one-liner:

/bin/bash /volume1/scripts/backup-mysql.sh

Then I can edit them from a PC over SMB, keep them in Git, and copy the folder to another NAS.

Boot and shutdown triggers

Create → Triggered Task → User-defined script lets you pick Boot-up or Shutdown as the event. Typical uses on my units: starting a service that the Docker package would otherwise start too early, and unmounting an encrypted share at shutdown. Example boot-up task that waits for Docker before starting a compose project:

#!/bin/bash
until /usr/local/bin/docker info >/dev/null 2>&1; do sleep 5; done
cd /volume1/docker/monitoring && /usr/local/bin/docker-compose up -d

Built-in task types

Besides user scripts, Create → Scheduled Task offers ready-made ones: Beep Control, Service, Recycle Bin and DSM Auto Update. The Recycle Bin task is the one everybody should have. Create → Scheduled Task → Recycle Bin → Empty all recycle bins → Retention policy → Delete files that are older than 30 days. Otherwise recycle bins quietly eat the volume.

What cron actually runs

Everything the GUI creates lands in the system crontab, which is useful for checking timing:

sudo cat /etc/crontab

Lines look like 30 3 * * * root /usr/syno/bin/synoschedtask --run id=12. The id refers to the task; do not edit this file by hand, because Task Scheduler rewrites it whenever you save a task.

Testing a task

Select the task → Run. Then Action → View Result (if output saving is enabled) or check your inbox for the report. For scheduled runs, confirm the timestamps of the log file change at the expected hour, and check the system log:

sudo grep synoschedtask /var/log/messages | tail

Entries show each start with the task ID and exit code.

Things that bit me

  • The script works over SSH but fails in Task Scheduler with "command not found": PATH in the task environment is short. Use full paths, or add export PATH=/usr/local/bin:/usr/bin:/bin:/usr/syno/bin at the top.
  • Output emails never arrive: Control Panel → Notification → Email must be configured and tested first; Task Scheduler uses that setting.
  • A task shows "Interrupted" in the log: it was still running when DSM shut down, or you clicked Stop. Long jobs should run under nohup or be split.
  • A script using sudo hangs: there is no TTY for the password prompt. Run the whole task as root instead.

A script that "works over SSH" has proven nothing yet. Run it from Task Scheduler at least once before you rely on it.