6 ms·

It’s not gross. It’s a simple solution to a simple and common cron problem Just because it doesn’t consider external executions, it doesn’t mean it’s a bad sol

It’s not gross. It’s a simple solution to a simple and common cron problem Just because it doesn’t consider external executions, it doesn’t mean it’s a bad solution. Horses for courses etc

pengaru 3y ago
> It’s not gross. It’s a simple solution to a simple and common cron problem No, it's gross. By providing that facility in the wrong place it discourages implementing it in the right place to people who come at the problem from the cron perspective. Wrap the command in a flock-running script. That script goes in the crontab entry. When you're inevitably debugging your cron-scheduled command - paydirt! The command serializes itself still while you're manually testing instead of shitting itself.
- eska 3y ago
  Isn’t that the same? Just because you check a file lock in your script doesn’t mean that other invocations of the program without the script will check the lock.
  - pengaru 3y ago
    No, it's not the same. The crontab entry reflects what you'd run to reproduce what the crontab does.
    - eska 3y ago
      Ok, but your original criticism stated that solving this in cron is bad because the program may be run outside of cron: * It's not just cron that can cause concurrent execution, and if that matters you generally want to robustly prevent it - not just if cron is the executor.* So you did not like that exclusion only worked when triggered from cron. But in your case it also only works when triggered from your script. So cron just made your script an integrated feature and you’re essentially criticizing your own solution.
  - Apofis 3y ago
    Lock files in scripts are actually pretty unreliable, learned this the really hard way and the lesson cost $10's of thousands of dollars.
    - r3trohack3r 3y ago
      Surprised to see this, mind sharing the experience? How did the lock fail? Was there a more reliable fix?

It’s not gross. It’s a simple solution to a simple and common cron problem Just because it doesn’t consider external executions, it doesn’t mean it’s a bad solution. Horses for courses etc

pengaru 3y ago

> It’s not gross. It’s a simple solution to a simple and common cron problem No, it's gross. By providing that facility in the wrong place it discourages implementing it in the right place to people who come at the problem from the cron perspective. Wrap the command in a flock-running script. That script goes in the crontab entry. When you're inevitably debugging your cron-scheduled command - paydirt! The command serializes itself still while you're manually testing instead of shitting itself.

eska 3y ago
Isn’t that the same? Just because you check a file lock in your script doesn’t mean that other invocations of the program without the script will check the lock.
- pengaru 3y ago
  No, it's not the same. The crontab entry reflects what you'd run to reproduce what the crontab does.
  - eska 3y ago
    Ok, but your original criticism stated that solving this in cron is bad because the program may be run outside of cron: * It's not just cron that can cause concurrent execution, and if that matters you generally want to robustly prevent it - not just if cron is the executor.* So you did not like that exclusion only worked when triggered from cron. But in your case it also only works when triggered from your script. So cron just made your script an integrated feature and you’re essentially criticizing your own solution.
- Apofis 3y ago
  Lock files in scripts are actually pretty unreliable, learned this the really hard way and the lesson cost $10's of thousands of dollars.
  - r3trohack3r 3y ago
    Surprised to see this, mind sharing the experience? How did the lock fail? Was there a more reliable fix?