实际上，尽管bmdhacks的答案几乎很好，但在第一次检查锁文件之后和在写入它之前，第二个脚本有轻微的机会运行。它们都将写入锁文件，它们都将运行。以下是如何确保它有效的方法:

lockfile=/var/lock/myscript.lock

if ( set -o noclobber; echo "$$" > "$lockfile") 2> /dev/null ; then
  trap 'rm -f "$lockfile"; exit $?' INT TERM EXIT
else
  # or you can decide to skip the "else" part if you want
  echo "Another instance is already running!"
fi

如果文件已经存在，noclobber选项将确保重定向命令将失败。因此，重定向命令实际上是原子的—您用一个命令写入和检查文件。你不需要在文件的末尾删除锁文件-它会被陷阱删除。我希望这对以后读到它的人有帮助。

另外，我没有看到Mikel已经正确地回答了这个问题，尽管他没有包括trap命令，以减少使用Ctrl-C停止脚本后留下锁文件的机会。这就是完整的解

下面是一个使用锁文件并将PID回显到锁文件中的实现。如果进程在删除pidfile之前被杀死，这可以起到保护作用:

LOCKFILE=/tmp/lock.txt
if [ -e ${LOCKFILE} ] && kill -0 `cat ${LOCKFILE}`; then
    echo "already running"
    exit
fi

# make sure the lockfile is removed when we exit and then claim it
trap "rm -f ${LOCKFILE}; exit" INT TERM EXIT
echo $$ > ${LOCKFILE}

# do stuff
sleep 1000

rm -f ${LOCKFILE}

这里的技巧是kill -0，它不传递任何信号，只是检查具有给定PID的进程是否存在。此外，调用trap将确保即使进程被杀死(kill -9除外)，锁文件也会被移除。

if [ 1 -ne $(/bin/fuser "$0" 2>/dev/null | wc -w) ]; then
    exit 1
fi

下面这一行的回答来自一个与Ask Ubuntu问答相关的人:

[ "${FLOCKER}" != "$0" ] && exec env FLOCKER="$0" flock -en "$0" "$0" "$@" || :
#     This is useful boilerplate code for shell scripts.  Put it at the top  of
#     the  shell script you want to lock and it'll automatically lock itself on
#     the first run.  If the env var $FLOCKER is not set to  the  shell  script
#     that  is being run, then execute flock and grab an exclusive non-blocking
#     lock (using the script itself as the lock file) before re-execing  itself
#     with  the right arguments.  It also sets the FLOCKER env var to the right
#     value so it doesn't run again.

这个我在任何地方都没有发现，它使用read，我不确切地知道read是否实际上是原子的，但到目前为止它对我来说很有用……它很有趣，因为它只是bash内置的，这是一个进程内实现，你启动locker协进程并使用它的I / O来管理锁，同样可以在进程间完成，只需将目标I / O从locker文件描述符交换到文件系统上的文件描述符(exec 3<>/file && exec 4</file)

## gives locks
locker() {
    locked=false
    while read l; do
        case "$l" in
            lock)
                if $locked; then
                    echo false
                else
                    locked=true
                    echo true
                fi
                ;;
            unlock)
                if $locked; then
                    locked=false
                    echo true
                else
                    echo false
                fi
                ;;
            *)
                echo false
                ;;
        esac
    done
}
## locks
lock() {
    local response
    echo lock >&${locker[1]}
    read -ru ${locker[0]} response
    $response && return 0 || return 1
}

## unlocks
unlock() {
    local response
    echo unlock >&${locker[1]}
    read -ru ${locker[0]} response
    $response && return 0 || return 1
}

我发现bmdhack的解决方案是最实用的，至少对我的用例来说是这样。使用flock和lockfile依赖于在脚本终止时使用rm删除lockfile，这不能总是得到保证(例如，kill -9)。

关于bmdhack的解决方案，我要改变一件小事:它强调删除锁文件，但没有说明这对于这个信号量的安全工作是不必要的。他使用kill -0来确保死进程的旧锁文件将被忽略/覆盖。

因此，我的简化解决方案是简单地将以下内容添加到单例的顶部:

## Test the lock
LOCKFILE=/tmp/singleton.lock 
if [ -e ${LOCKFILE} ] && kill -0 `cat ${LOCKFILE}`; then
    echo "Script already running. bye!"
    exit 
fi

## Set the lock 
echo $$ > ${LOCKFILE}

当然，这个脚本仍然有一个缺陷，即可能同时启动的进程存在竞争风险，因为锁定测试和设置操作不是单个原子动作。但是lhunath提出的使用mkdir的解决方案有一个缺陷，即被杀死的脚本可能会留下目录，从而阻止其他实例运行。