As told above, a special tool for locking is the 100% solution. You dont have race conditions, you dont need to work around specific limits, and all those issues.

The best way to set a global lock condition is the UNIX® filesystem. Variables arent enough, as each process has its own private variable space, but the filesystem is global to all processes (yes, I know about chroots, namespaces, … special case).

You can "set" several things in a filesystem that can be used as locking indicator:

To create a file or set a file timestamp, usually the command touch is used. That implies the following problem:

A locking mechanism would check the existance of the lockfile, if it doesnt exist, it would create one (lock) and continue. These are two steps! That means, its not one atomic operation

. Theres a small amount of time between checking and creating, where another instance of the same script could perform locking (because when it checked, the lockfile wasnt there)! In that case you would have 2 instances of the script running, both think they succesfully locked, and both think they can operate without collisions.

Setting the timestamp would be similar: One step to check the timespamp, a second step to set the timestamp.

A simple way to get that is to create a lock directory - the mkdir command. It will

With mkdir it seems, we have our two steps in one simple operation. A (very!) simple locking code might look like this now:

if mkdir /var/lock/mylock; then echo "Locking succeeded" >&2 else echo "Lock failed - exit" >&2 exit 1 fi

In case mkdir reports an error, the script will exit at this point - the MUTEX did its job!

In case the directory is removed after setting a successful lock while the script is still running, the lock is lost.Doing chmod -w for parent directory containing the lock directory can be done but it is also not atomic.Maybe a while loop checking continously for the existence of the lock in background and sending a signal such as USR1 if the directory is found non-existent can be done.The signal would need to be trapped.I am sure there would be a better solution than this suggestion — sn18 2009/12/19 08:24

Note: On my way through the Internet I found some people wondering if the mkdir way will work "on all filesystems". Well, lets say it should. The syscall under mkdir is guarenteed to work atomic in all cases, at least on Unices. A problem can be a shared filesystem on NFS or a real cluster filesystem. There it depends on the mount options and the implementation. However, I successfully use this simple way on top of an Oracle OCFS2 filesystem in a 4-node cluster environment. So lets just say "its expected to work under normal conditions".

Another atomic method is setting the noclobber shell option (set -C), which will cause a redirection to fail if the file the redirection points to already exists (using diverse open() methods). This is also a very nice way, and I use this more simple locking method successfully in production, too. Need to write a code example here.

if ( set -o noclobber; echo "locked" > "$lockfile") 2> /dev/null; then trap rm -f "$lockfile"; exit $? INT TERM EXIT echo "Locking succeeded" >&2 rm -f "$lockfile" else echo "Lock failed - exit" >&2 exit 1 fi

This code was taken from a script that controls PISG to create statistical pages from my IRC logfiles. It doesnt matter for you, I just note that to tell you that this code works and is used.

There are some additional things compared to the very simple example above:

I dont show various details - like determinating the signal by which the script was killed - here, I just show the most relevant code:

#!/bin/bash # lock dirs/files LOCKDIR="/tmp/statsgen-lock" PIDFILE="${LOCKDIR}/PID" # exit codes and text for them - additional features nobody needs :-) ENO_SUCCESS=0; ETXT[0]="ENO_SUCCESS" ENO_GENERAL=1; ETXT[1]="ENO_GENERAL" ENO_LOCKFAIL=2; ETXT[2]="ENO_LOCKFAIL" ENO_RECVSIG=3; ETXT[3]="ENO_RECVSIG" ### ### start locking attempt ### trap ECODE=$?; echo "[statsgen] Exit: ${ETXT[ECODE]}($ECODE)" >&2 0 echo -n "[statsgen] Locking: " >&2 if mkdir "${LOCKDIR}" &>/dev/null; then # lock succeeded, install signal handlers before storing the PID just in case # storing the PID fails trap ECODE=$?; echo "[statsgen] Removing lock. Exit: ${ETXT[ECODE]}($ECODE)" >&2 rm -rf "${LOCKDIR}" 0 echo "$" >"${PIDFILE}" # the following handler will exit the script on receiving these signals # the trap on "0" (EXIT) from above will be triggered by this traps "exit" command! trap echo "[statsgen] Killed by a signal." >&2 exit ${ENO_RECVSIG} 1 2 3 15 echo "success, installed signal handlers" else # lock failed, now check if the other PID is alive OTHERPID="$(cat "${PIDFILE}")" # if cat wasnt able to read the file anymore, another instance probably is # about to remove the lock -- exit, were *still* locked # Thanks to Grzegorz Wierzowiecki for pointing this race condition out on # http://wiki.grzegorz.wierzowiecki.pl/code:mutex-in-bash if [ $? != 0 ]; then echo "lock failed, PID ${OTHERPID} is active" >&2 exit ${ENO_LOCKFAIL} fi if ! kill -0 $OTHERPID &>/dev/null; then # lock is stale, remove it and restart echo "removing stale lock of nonexistant PID ${OTHERPID}" >&2 rm -rf "${LOCKDIR}" echo "[statsgen] restarting myself" >&2 exec "$0" "$@" else # lock is valid and OTHERPID is active - exit, were locked! echo "lock failed, PID ${OTHERPID} is active" >&2 exit ${ENO_LOCKFAIL} fi fi

声明：本站所有文章 
  
  
  
  
  
 ，如无特殊说明或标注 
  
  
  
  
  
  ，均为本站原创发布             。任何个人或组织

 


 


 


 


 


 

，在未征得本站同意时 
 
 
 
 
 
，禁止复制             、盗用
 
  
 
  
 
  
 
  
 
  
 
  
、采集











、发布本站内容到任何网站  
  
  
  
  
  
 、书籍等各类媒体平台
 
  
 
  
 
  
 
  
 
  
 
  
。如若本站内容侵犯了原著者的合法权益 
   
   
   
   
   
   ，可联系我们进行处理











。