5 ms·

Another nicety OpenBSD's cron gained not long ago was the "-s" flag to ensure only a single instance of command will be run concurrently. https://man.openbsd.o

Another nicety OpenBSD's cron gained not long ago was the "-s" flag to ensure only a single instance of command will be run concurrently. https://man.openbsd.org/man5/crontab.5#s https://man.openbsd.org/man5/crontab.5#s

hnlmorg 3y ago
Today I learned the -n flag. Is this also an OpenBSD exclusive? I have to say, these flags are a really nice enhancement to cron.
- networked 3y ago
  FreeBSD and NetBSD also implement "-n". There doesn't seem to be a cross-platform port of OpenBSD cron like there are of doas and OpenBSD ksh. (Anybody want to try making one?) Cross-platform fcron has "erroronlymail". https://man.freebsd.org/cgi/man.cgi?query=crontab&apropos=0&sektion=5&manpath=FreeBSD+13.2-RELEASE+and+Ports&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=crontab&apropos=0&... https://man.netbsd.org/NetBSD-9.3-STABLE/crontab.5 https://man.netbsd.org/NetBSD-9.3-STABLE/crontab.5 http://fcron.free.fr/doc/en/fcrontab.5.html#FCRONTAB.5.ERRORONLYMAIL http://fcron.free.fr/doc/en/fcrontab.5.html#FCRONTAB.5.ERROR...
pengaru 3y ago
That's gross. If the operation shouldn't run concurrently it should use an exclusive flock or similar. 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.
- thiagocsf 3y ago
  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.
        3y ago
- justsomehnguy 3y ago
  Ah, yes, lets add exclusive flock support to all binaries in the existence, just in case. You are confusing running a process with running a task from scheduler.
  - pengaru 3y ago
    > Ah, yes, lets add exclusive flock support to all binaries in the existence, just in case. 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?
    - justsomehnguy 3y ago
      > You are aware that flock(1) is a thing, right? 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.
      - pengaru 3y ago
        [flagged]
        justsomehnguy 3y ago
        > efore you dig that hole of incompetence any deeper. "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.
        gsich 3y ago
        Better look into a mirror ... Using cron (or systemd) to ensure only 1 instance is running is a valid approach.
- mjw1007 3y ago
  I think it's fine for the case where running the operation more than once at a time isn't incorrect, but potentially wastes resources.
- progmetaldev 3y ago
  You are of course correct, but at the same time, you might (or probably not) be surprised at the number of "system administrators" that are thrown into the job without really having the capability to expand too far on their knowledge. Having the option in cron may help those administrators that specifically search Google for cron usage, and never come across flock. 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
- mlyle 3y ago
  If your job is a real script: sure, handle locking in it. 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.
  - agapon 3y ago
    You don't have to create a script, running a command under flock is still a one-liner in crontab.
    - mlyle 3y ago
      But it's unnecessary when you can do the same thing in 2 characters. 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.
- aflag 3y ago
  Even though a process can be run concurrently, it doesn’t mean you necessarily want to. Besides that, your cron itself may be something like “do-something | grep foo > /root/bar”. You obviously don’t want to run that concurrently. You could create a script, but that’s more cumbersome.
mekster 3y ago
An external program but there's run-one program in Ubuntu repo.

hnlmorg 3y ago

Today I learned the -n flag. Is this also an OpenBSD exclusive? I have to say, these flags are a really nice enhancement to cron.

networked 3y ago
FreeBSD and NetBSD also implement "-n". There doesn't seem to be a cross-platform port of OpenBSD cron like there are of doas and OpenBSD ksh. (Anybody want to try making one?) Cross-platform fcron has "erroronlymail". https://man.freebsd.org/cgi/man.cgi?query=crontab&apropos=0&sektion=5&manpath=FreeBSD+13.2-RELEASE+and+Ports&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=crontab&apropos=0&... https://man.netbsd.org/NetBSD-9.3-STABLE/crontab.5 https://man.netbsd.org/NetBSD-9.3-STABLE/crontab.5 http://fcron.free.fr/doc/en/fcrontab.5.html#FCRONTAB.5.ERRORONLYMAIL http://fcron.free.fr/doc/en/fcrontab.5.html#FCRONTAB.5.ERROR...

pengaru 3y ago

That's gross. If the operation shouldn't run concurrently it should use an exclusive flock or similar. 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.

thiagocsf 3y ago
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.
      - 3y ago
justsomehnguy 3y ago
Ah, yes, lets add exclusive flock support to all binaries in the existence, just in case. You are confusing running a process with running a task from scheduler.
- pengaru 3y ago
  > Ah, yes, lets add exclusive flock support to all binaries in the existence, just in case. 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?
  - justsomehnguy 3y ago
    > You are aware that flock(1) is a thing, right? 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.
    - pengaru 3y ago
      [flagged]
      - justsomehnguy 3y ago
        > efore you dig that hole of incompetence any deeper. "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.
      - gsich 3y ago
        Better look into a mirror ... Using cron (or systemd) to ensure only 1 instance is running is a valid approach.
mjw1007 3y ago
I think it's fine for the case where running the operation more than once at a time isn't incorrect, but potentially wastes resources.
progmetaldev 3y ago
You are of course correct, but at the same time, you might (or probably not) be surprised at the number of "system administrators" that are thrown into the job without really having the capability to expand too far on their knowledge. Having the option in cron may help those administrators that specifically search Google for cron usage, and never come across flock. 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
mlyle 3y ago
If your job is a real script: sure, handle locking in it. 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.
- agapon 3y ago
  You don't have to create a script, running a command under flock is still a one-liner in crontab.
  - mlyle 3y ago
    But it's unnecessary when you can do the same thing in 2 characters. 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.
aflag 3y ago
Even though a process can be run concurrently, it doesn’t mean you necessarily want to. Besides that, your cron itself may be something like “do-something | grep foo > /root/bar”. You obviously don’t want to run that concurrently. You could create a script, but that’s more cumbersome.

mekster 3y ago

An external program but there's run-one program in Ubuntu repo.