9 ms·

Yes but anacron is still a bit less powerful than timers, since I can schedule a timer to run every hour instead of once an hour plus on reboot in two very shor

by zaarn 5y ago

Yes but anacron is still a bit less powerful than timers, since I can schedule a timer to run every hour instead of once an hour plus on reboot in two very short config lines. And I don't think anacron has a concept of running things every hours not including runtime, only including runtime.

pnutjam 5y ago
you just drop your script in /etc/cron.hourly.
- zaarn 5y ago
  That runs it once an hour not every hour, there is an important distinction there.
  - pnutjam 5y ago
    Please elaborate on why this might matter? I can't think of any scenarios.
    - zaarn 5y ago
      It helps dispersing jobs like backups. If you have 20 servers, your backup storage is not hit by them all at the same time. Even better, because it takes into account how long it runs, if two servers hit it at the same time, the reduced performance will automatically spread the server that took longer behind the other. That scheme reduced the needed capacity in network and CPU of our backup servers a lot. If it ran every hour, all servers would either hit the backup store at the same time or you would have to manually disperse them. Randomized Delay is great if you want to avoid this problem with short running jobs but it doesn't work well when most jobs take 10 minutes or more and the delay becomes larger than the timer's repeat interval. So in that case, using a "run every 60 minutes" scheme is a massive advantage that reduces coordination needs.
      - pnutjam 5y ago
        Then you'd put that in cron.d/ something like 5 * * * * would run at 12:05, 1:05, 2:05, 3:05, etc...
        zaarn 5y ago
        And every server will have to be put on a different schedule. By running it every 60 minutes, it doesn't matter when it runs, it automatically aligns. Once you managed 200 servers, that becomes valuable and no longer manually managable ("How many servers are running backups on :05? Do I need to move some? Can I fit in one more?")

by zaarn 5y ago

pnutjam 5y ago

you just drop your script in /etc/cron.hourly.

zaarn 5y ago
That runs it once an hour not every hour, there is an important distinction there.
- pnutjam 5y ago
  Please elaborate on why this might matter? I can't think of any scenarios.
  - zaarn 5y ago
    It helps dispersing jobs like backups. If you have 20 servers, your backup storage is not hit by them all at the same time. Even better, because it takes into account how long it runs, if two servers hit it at the same time, the reduced performance will automatically spread the server that took longer behind the other. That scheme reduced the needed capacity in network and CPU of our backup servers a lot. If it ran every hour, all servers would either hit the backup store at the same time or you would have to manually disperse them. Randomized Delay is great if you want to avoid this problem with short running jobs but it doesn't work well when most jobs take 10 minutes or more and the delay becomes larger than the timer's repeat interval. So in that case, using a "run every 60 minutes" scheme is a massive advantage that reduces coordination needs.
    - pnutjam 5y ago
      Then you'd put that in cron.d/ something like 5 * * * * would run at 12:05, 1:05, 2:05, 3:05, etc...
      - zaarn 5y ago
        And every server will have to be put on a different schedule. By running it every 60 minutes, it doesn't matter when it runs, it automatically aligns. Once you managed 200 servers, that becomes valuable and no longer manually managable ("How many servers are running backups on :05? Do I need to move some? Can I fit in one more?")