It uses state files in /var/spool/cron/lastrun/ to know when each interval was last run, so it only runs once per period. But: the age threshold for
the state file is period + 5 minutes. Shouldn’t that be period - 5 minutes?
My reasoning: assume run-crons is run hourly, at the 0 minute sharp. So at the next run, the state file is exactly one hour old. Since this is not old enough for the check, run-crons thinks that the last run is too recent and ignores this period. As a result, each period is only run on every other iteration.
On Sun, Dec 12, 2021 at 1:21 PM Frank Steinmetzger <Warp_7@gmx.de> wrote:
It uses state files in /var/spool/cron/lastrun/ to know when each interval was last run, so it only runs once per period. But: the age threshold for the state file is period + 5 minutes. Shouldn’t that be period - 5 minutes?
My reasoning: assume run-crons is run hourly, at the 0 minute sharp. So at the next run, the state file is exactly one hour old. Since this is not old enough for the check, run-crons thinks that the last run is too recent and ignores this period. As a result, each period is only run on every other iteration.
I don't use this, but I believe there should be an hourly crontab
entry that deletes the cron.hourly file, which would mean it gets run
on the next 10min cycle (or maybe sooner - I'm not sure if those jobs
are run in parallel or serial).
Am Sun, Dec 12, 2021 at 01:41:33PM -0500 schrieb Rich Freeman:
On Sun, Dec 12, 2021 at 1:21 PM Frank Steinmetzger <Warp_7@gmx.de> wrote:
I don't use this, but I believe there should be an hourly crontab
entry that deletes the cron.hourly file, which would mean it gets run
on the next 10min cycle (or maybe sooner - I'm not sure if those jobs
are run in parallel or serial).
The check that I mentioned above is actually the deletion which you mention: run-crons looks for the state file for the given interval and - if it is old enough - deletes it.
For the record: The checks in run-crons that I referred to earlier are actually more for those cases in which the machine was powered off for a while in order to restore cron completeness as early as possible after boot.
On Sun, Dec 12, 2021 at 2:07 PM Frank Steinmetzger <Warp_7@gmx.de> wrote:
Am Sun, Dec 12, 2021 at 01:41:33PM -0500 schrieb Rich Freeman:
On Sun, Dec 12, 2021 at 1:21 PM Frank Steinmetzger <Warp_7@gmx.de> wrote:
I don't use this, but I believe there should be an hourly crontab
entry that deletes the cron.hourly file, which would mean it gets run
on the next 10min cycle (or maybe sooner - I'm not sure if those jobs
are run in parallel or serial).
The check that I mentioned above is actually the deletion which you mention:
run-crons looks for the state file for the given interval and - if it is old
enough - deletes it.
The check I'm talking about isn't in run-crons at all. It is in /etc/crontab. It doesn't look at the age of the file and
unconditionally deletes it every hour:
59 * * * * rm -f /var/spool/cron/lastrun/cron.hourly
On Mon, 2021-12-13 at 22:19 +0100, Frank Steinmetzger wrote:
For the record: The checks in run-crons that I referred to earlier are actually more for those cases in which the machine was powered off for a while in order to restore cron completeness as early as possible after boot.
The run-crons quackery has been causing problems since 2004:
https://bugs.gentoo.org/69777
One-liners with run-parts (NOT run-crons) are a lot more predictable.
On Mon, 2021-12-13 at 22:38 +0100, Frank Steinmetzger wrote:
Well I *could* disable run-crons altogether and add entries to fcron’s own
crontab which would run those scripts in /etc/cron.{hourly,daily,...} instead.
However, I like predictable times at which those jobs will run. Especially if one of them is a zfs scrub; the NAS is powered down for weeks, sometimes months. And when I power it up, it’s for a reason. And that reason usually
is not a scrub, which—at the current zfs fill level—takes 10½ hours.
Why choose fcron then? It sounds like you have the same rationale as I
do: "no, I don't want to run the 4am backup job in the middle of the
business day just because it wasn't run at 4am."
If you pick a dumber cron, the crontab entries are run only at the
specified times.
On Mon, Dec 13, 2021 at 4:42 PM Michael Orlitzky <mjo@gentoo.org> wrote:
On Mon, 2021-12-13 at 22:38 +0100, Frank Steinmetzger wrote:
Well I *could* disable run-crons altogether and add entries to fcron’s own
crontab which would run those scripts in /etc/cron.{hourly,daily,...} instead.
However, I like predictable times at which those jobs will run. Especially
if one of them is a zfs scrub; the NAS is powered down for weeks, sometimes
months. And when I power it up, it’s for a reason. And that reason usually
is not a scrub, which—at the current zfs fill level—takes 10½ hours.
Why choose fcron then? It sounds like you have the same rationale as I
do: "no, I don't want to run the 4am backup job in the middle of the business day just because it wasn't run at 4am."
fcron is perfectly capable of running jobs at either set times or at loosely-defined intervals that are compensated for if the machine is
off.
Systemd timers can also be set that way, and can also have
limits put on scheduling (daily nominally at 3AM but allowed between
11PM and 5AM or whatever). Obviously the more expressive the crontab equivalent is, the more you can tweak it to do what you want it to.
I'll also note that zfs scrubs checkpoint at shutdown and will
auto-resume where you leave off.
If they are involved multiple times
with the default options I think any attempt to scrub something that
is already being scrubbed is just a no-op. Obviously if you don't
want all that IO during the day you'll have to do something more
clever - you can instruct it to pause and resume so you could have a
couple of crontab entries and scripts to do just that.
If they are involved multiple times
with the default options I think any attempt to scrub something that
is already being scrubbed is just a no-op. Obviously if you don't
want all that IO during the day you'll have to do something more
clever - you can instruct it to pause and resume so you could have a
couple of crontab entries and scripts to do just that.
Or, since I am the only user of that system, I could go back to my previous way: just run the scrub manually every other month or so before I go to bed. Because then I know that nothing will interfere with it and it won’t interfere with anything else.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 65:07:32 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,274,919 |