Bug 36229 - koha-run-backups should be first daily job
Summary: koha-run-backups should be first daily job
Status: Pushed to main
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor
Assignee: David Cook
QA Contact: Marcel de Rooy
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-03-05 04:49 UTC by David Cook
Modified: 2025-01-28 02:31 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
This fixes the order of the daily cron jobs (/etc/cron.daily/koha-common) so that koha-run-backups is run first. Reasons for this include: 1. The koha-run-backups cron job takes a backup before running scripts that change database contents. If there is a problem with those scripts, you'll have a very recent backup on which to fallback. 2. It's a resource intensive job. If you have a lot of Koha instances, this means you're running your most intensive job at the end of the job run, which might be a lot later in the day than you anticipate. (Of course, you can update /etc/crontab to change when /etc/cron.daily is run, but this will help reduce impact in the meantime.) Deployment of this change: - New installations: This change will seamlessly apply for new installations. - Existing installations: . You HAVEN'T manually modified the crontab: it will seamlessly apply. . You HAVE manually modified the crontab: you will be prompted, and will need to decide about applying the change. . Where deployment tools are used (such as Ansible): this will depend on what tools you use and how they are configured.
Version(s) released in:
25.05.00
Circulation function:


Attachments
Bug 36229: Move koha-run-backups to the top of the cron (1.51 KB, patch)
2025-01-08 13:40 UTC, Imani
Details | Diff | Splinter Review
Bug 36229: Move koha-run-backups to the top of the cron (1.56 KB, patch)
2025-01-09 08:57 UTC, David Nind
Details | Diff | Splinter Review
Bug 36229: Move koha-run-backups to the top of the cron (1.66 KB, patch)
2025-01-10 09:30 UTC, Marcel de Rooy
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2024-03-05 04:49:59 UTC
There's a couple of reasons why koha-run-backups should be the first job in /etc/cron.daily/koha-common.

1. It takes a backup before running scripts that change database contents. If there is a problem with those scripts, you'll have a very recent backup on which to fallback.

2. It's a resource intensive job. If you have a lot of Koha instances, this means you're running your most intensive job at the end of the job run, which might be a lot later in the day than you anticipate. (Of course, you can update /etc/crontab to change when /etc/cron.daily is run, but this will help reduce impact in the meantime.)
Comment 1 Imani 2025-01-08 13:40:19 UTC
Created attachment 176230 [details] [review]
Bug 36229: Move koha-run-backups to the top of the cron

test plan:
    1. check run order of scripts in the cron
    2. apply patch
    3. koha-run-backups is now at the beginning of the cron
Comment 2 David Nind 2025-01-09 08:57:24 UTC
Created attachment 176284 [details] [review]
Bug 36229: Move koha-run-backups to the top of the cron

test plan:
    1. check run order of scripts in the cron
    2. apply patch
    3. koha-run-backups is now at the beginning of the cron

Signed-off-by: David Nind <david@davidnind.com>
Comment 3 Marcel de Rooy 2025-01-10 09:30:48 UTC
Created attachment 176315 [details] [review]
Bug 36229: Move koha-run-backups to the top of the cron

test plan:
    1. check run order of scripts in the cron
    2. apply patch
    3. koha-run-backups is now at the beginning of the cron

Signed-off-by: David Nind <david@davidnind.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 4 Katrin Fischer 2025-01-10 18:20:45 UTC
Pushed for 25.05!

Well done everyone, thank you!
Comment 5 David Nind 2025-01-28 01:41:50 UTC
I've added a release note, but a quick question: Will this change only fix this for new installations?

If it does, I'll add a note that this change will need to be made manually for existing installations.
Comment 6 David Cook 2025-01-28 02:11:29 UTC
(In reply to David Nind from comment #5)
> I've added a release note, but a quick question: Will this change only fix
> this for new installations?
> 
> If it does, I'll add a note that this change will need to be made manually
> for existing installations.

It's complicated.

It will seamlessly apply for new installations, it will seamlessly apply for existing installations where the crontab hasn't been previously manually modified.

For existing installations where the crontab has been previously manually modified, sysadmins will be prompted to decide whether or not to apply the change. (Deployment tools like Ansible are often set to automatically accept changes, so automated deployments often will apply the change, but it will vary by individual implementation.)
Comment 7 David Nind 2025-01-28 02:31:23 UTC
(In reply to David Cook from comment #6)
> (In reply to David Nind from comment #5)
> > I've added a release note, but a quick question: Will this change only fix
> > this for new installations?
> > 
> > If it does, I'll add a note that this change will need to be made manually
> > for existing installations.
> 
> It's complicated.
> 
> It will seamlessly apply for new installations, it will seamlessly apply for
> existing installations where the crontab hasn't been previously manually
> modified.
> 
> For existing installations where the crontab has been previously manually
> modified, sysadmins will be prompted to decide whether or not to apply the
> change. (Deployment tools like Ansible are often set to automatically accept
> changes, so automated deployments often will apply the change, but it will
> vary by individual implementation.)

Thanks for the great explanation David! I've updated the release note to hopefully reflect this.