我正在寻找一个命令行实用程序或其他方式来testing文件锁的有效性，特别是在Linux文件系统中的POSIX顾问锁 （不仅适用于POSIX，btw）。
具体来说，我想确保POSIXbuild议locking（文件locking）在Linux / Ubuntu VM中用于持续集成testing的simfs中正常工作。 当有30个进程并发写入时，我们的文件损坏只发生在SQLite数据库文件中。 这只用于一个项目的testing，但是我们想帮助追踪这个问题，这样其他人就不会遇到这个问题。
根据SQLite团队和文档，只有当POSIX顾问锁在文件系统/操作系统中工作时才支持并发写操作。 我使用SQLite的testing在OS X的SQLite v3.7.7中工作，但同样的testing在TravisCI提供的Ubuntu VM中（由Blue Box托pipe）破坏SQLite v3.7.9中的数据库文件。 SQLite团队没有指出这两个版本之间有任何并发问题，因为并发依赖于OS /文件系统的POSIX顾问锁的工作。
有关我正在调查的环境的其他信息：
$ sqlite3 -version 3.7.9 2011-11-01 00:52:41 c7c6050ef060877ebe77b41d959e9df13f8c9b5e $ uname -r 2.6.32-042stab061.2 $ cat /proc/version Linux version 2.6.32-042stab061.2 (root@rh6-build-x64) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Fri Aug 24 09:07:21 MSK 2012 $ lsb_release -a Distributor ID: Ubuntu Description: Ubuntu 12.04.2 LTS Release: 12.04 Codename: precise (home dir it that is exhibiting the problem is within the / mount.) $ cat /proc/mounts /dev/simfs / simfs rw,relatime 0 0 ... $ mount /vz/private/6062841 on / type simfs (rw) ... 我在那里提供虚拟机，他们表示他们没有使用networking文件系统，这通常与POSIX锁相关的问题有关，因为在这样的环境中实现POSIX锁是非常复杂的。 除了上面的信息，虽然这个新闻稿似乎表明OpenStack正在使用，上面的path显示“vz”在挂载，使得它似乎OpenVZ正在使用。
至于帮助诊断POSIXlocking失败的工具，唯一一个我听说过的是乒乓testing，它是testingPOSIXlockingSamba的smbtorture的一部分，但是在这种情况下我没有使用Samba，我不确定这会有帮助。
如果没有可用的命令行testing，我将如何去testing它是否正在工作，如果我所有可用的是有限访问虚拟机（因为sudo不需要作为我的用户的密码，但命令应该使用sudo输出的东西不工作，所以我认为这是覆盖）？ 是否有命令，我可以让虚拟机pipe理员运行收集更多的信息来帮助解决这个问题？
首先：文件锁和pthread mutex是完全不同的野兽。 文件locking用于build议当前不使用文件的当前或其他进程。 Pthread互斥体仅用于在当前进程中协调线程之间的关键部分。
文件locking完成flock(2)和朋友，并且方便，它有一个shell脚本包装器。 要testing文件锁是否可用，请打开两个terminal并运行以下命令：
在terminal一：
flock /path/to/lockfile sleep 120
而在另一个terminal，而第一个拿着锁：
if ! flock -n /tmp/foo.lock true ; then echo "flock works"; else echo "flock fails"; fi
这应该告诉你是否文件locking工作。
如果你必须在一个脚本中运行它，试试这个：
flock /path/to/lockfile sleep 120 & if ! flock -n /tmp/foo.lock true ; then echo "flock works"; else echo "flock fails"; fi kill $!
locking文件的另一种方式是fcntl系统调用。 用ruby进行testing相当麻烦，但是这个python代码应该可以做到这一点：
import fcntl, os, time fd = open('/tmp/test.lock', 'w') if os.fork(): fcntl.lockf(fd, fcntl.LOCK_EX) os.wait() else: time.sleep(0.1) fcntl.lockf(fd, fcntl.LOCK_EX|fcntl.LOCK_NB)
它试图在两个不同的进程中locking相同的文件。 第二个锁是非阻塞的，所以应该马上提出一个错误。 预期的输出，如果fcntl锁正常工作，是：
Traceback (most recent call last): File "test.py", line 12, in <module> fcntl.lockf(fd, fcntl.LOCK_EX|fcntl.LOCK_NB) IOError: [Errno 11] Resource temporarily unavailable
我没有openvz虚拟机做testing，但我认为你需要阅读关于顾问locking的这个笔记，咨询locking需要参与进程的合作。 假设进程“A”获得一个WRITE锁，它开始写入文件，并且处理“B”，而不试图获取一个锁，它可以打开文件并写入文件。 这里的过程“B”是不合作的过程。 如果进程“B”试图获得一个锁，那么这意味着这个进程是合作的，以确保“序列化”。
只有参与过程是合作的，咨询locking才能起作用。 咨询locking有时也被称为“非强制”locking。