I have to say, these flags are a really nice enhancement to cron.

https://man.freebsd.org/cgi/man.cgi?query=crontab&apropos=0&...

https://man.netbsd.org/NetBSD-9.3-STABLE/crontab.5

http://fcron.free.fr/doc/en/fcrontab.5.html#FCRONTAB.5.ERROR...

Just because it doesn’t consider external executions, it doesn’t mean it’s a bad solution. Horses for courses etc

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.

* 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.

How did the lock fail? Was there a more reliable fix?

You are confusing running a process with running a task from scheduler.

You are aware that flock(1) is a thing, right? And that a defacto core tenet of UNIX is composability of disparate programs that do one thing well?

No. Maybe I heard and even knew what it is, but I never needed it.

You know why?

My task scheduler supports running only one instance of the task so I don't need to reinvent the wheel every time I need something to run on schedule.

Just 'somebinary args args args', 'run only one instance' and I'm done.

> flock - manage locks from shell scripts

Well, yep. Reinventing the wheel each other time.

Thanks, I have some more important things (like browsing HN) than writing shitty shell scripts.

...

> Thanks, I have some more important things (like browsing HN) than writing shitty shell scripts.

Probably a good idea, before you dig that hole of incompetence any deeper.

We're talking about crond here, which is already running the scheduled commands via sh, it's inherently involving the shell. Welcome to *NIX.

"Hur-dur! Look at me! Me mighty UNIX wizard! Bow to me!"

> running the scheduled commands via sh, it's inherently involving the shell. Welcome to *NIX.

Thanks, while you are running shell commands I'm running systems. I'm not interested in writing shell scripts for things what were solved decades ago.

Using cron (or systemd) to ensure only 1 instance is running is a valid approach.

Erm, no - flock(1) is a UNIX tool, a component if you will. It's the exact opposite of reinventing the wheel.

Not understanding the operating system you're using is fine, but it's good to at least know what you don't know.

If I need to write a wrapper script each time I need to run a task on a timer - then it is the proverbial reinventing the wheel. It doesn't matter if you call it a tool, utility or a component. Especially if this was solved decades ago.

> Not understanding the operating system you're using is fine

Ah, another mighty UNIX wizard here.

And there's your problem - you don't realize "writing a wrapper script" is actually simpler than messing with config files.

Come on, I would repeat it again - it was solved for decades. Why do you need to do the things like it's 1976? Why do you insist everyone else should do that way too and abandon the fruits of the digital age?

It was solved decades ago: in 1976. I don't understand why you feel like it wasn't.

cron goes completely against that principle - after all, you can schedule jobs with the 'at' command, and to make a repeating task, you just make it exec 'at' again each time it is called. cron is for the lazy, no real UNIX hacker would dream of using such an extravagant single-use program. /s

EDIT: In addition, the Task Scheduler in Windows has this type of option, so it may help those sys admins coming from that environment, leveraging their existing knowledge

If it's a single command or pipeline... adding the layer of indirection to have a script that runs flock is more opaque. Might as well put it in cron and trust cron to only run it once.

I like flock(1) and have known how to use it for 15 years. But there's sharp edges.

- It's not standardized. In particular, this means the OpenBSD base system doesn't even include it. It's not like the underlying flock(2) is very well behaved or consistent.

- You need to ask for nonblocking behavior.

- If your command or script can ever result in a daemon launching, it may be holding the lock even though the part of your action that is supposed to be protected by the lock (the script/immediate subprocess) has ceased. so e.g. 'flock -n /tmp/relaunch-apache /etc/init.d/apache2 restart' could be a really bad idea. -u can fix this... in some cases.