Skip to content

docker: run the scheduled sync once, not twice - #29

Merged
katbyte merged 3 commits into
mainfrom
kt/cron-runs-once
Oct 3, 2026
Merged

katbyte merged 3 commits into
mainfrom
kt/cron-runs-once

Conversation

@katbyte

@katbyte katbyte commented Oct 3, 2026 •

Copy link
Copy Markdown
Owner

The scheduled sync has been running twice at once; this makes it run once.

Why: every sync slot did the same work as two concurrent processes: double the GitHub API calls, and two writers stamping the same project items at the same time.

The crontab was registered twice. entry.sh writes the crontab to /etc/cron.d/crontab and then installs it with crontab. Alpine's dcron also reads /etc/cron.d by itself, so it saw the job in both places. A once-a-minute job in a plain Alpine container with those exact lines fires twice in the same second:

job ran: 21:34:01
job ran: 21:34:01

The file now lives in /app, so only the copy crontab installs exists; the same test fires once a minute.

-echo "$SYNC_CRON /app/scripts/run.sh 2>&1 | tee -a /var/log/ghp-sync.log" > /etc/cron.d/crontab
-chmod 0644 /etc/cron.d/crontab
-crontab /etc/cron.d/crontab
+echo "$SYNC_CRON /app/scripts/run.sh 2>&1 | tee -a /var/log/ghp-sync.log" > /app/crontab
+crontab /app/crontab

Fine as it is: the rest of entry.sh (the env copy, the log tail) is unchanged; shellcheck passes.

The crontab was written to /etc/cron.d and then installed again with
crontab. dcron reads /etc/cron.d on its own, so the job was registered
twice and every sync ran as two processes at once. The file now lives
in /app, so only the installed copy exists.
@katbyte
katbyte merged commit ac4d89d into main Oct 3, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant