2 ms·
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 fl
by mlyle 4y 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 4y agoYou don't have to create a script, running a command under flock is still a one-liner in crontab.
- mlyle 4y agoBut 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.