【问题标题】:Why do some commands require locks on Unix and others don't?为什么有些命令在 Unix 上需要锁而其他命令不需要?
【发布时间】:2013-01-28 02:45:51
【问题描述】:

最近,我在我们的环境 AIX 7.1 中观察到一些有趣的事情。为了追查问题,我用 Java 创建了一个小型锁定应用程序:

import java.io.File;
import java.io.RandomAccessFile;
import java.nio.channels.FileChannel;
import java.nio.channels.FileLock;
import java.nio.channels.OverlappingFileLockException;

public class Locker {

    public static void main(String[] args) throws Exception {
        File file = new File("/etc/passwd");
        FileChannel channel = new RandomAccessFile(file, "rw").getChannel();
        FileLock lock;

        try {
            lock = channel.tryLock();

            if (lock != null) {
                System.out.println("I have the lock");
                while(true) {}
            }

        } catch (OverlappingFileLockException e) {
            e.printStackTrace();
        }

    }
}

据我所知,这会在 /etc/passwd 上获得读写锁。如果我尝试运行此应用程序的两个实例,我只能按预期在一个实例中获得锁。同样,如果我运行这个命令:

su user2 -c echo test

该命令挂起,直到我从 Java 应用程序释放锁定。另一方面,读取文件:

cat /etc/passwd

成功运行。甚至写入文件:

cat /etc/passwd > /etc/passwd

也不错。现在,显然 Java FileLock 实现是系统相关的,并且由于这种性质,没有指定的行为。然而,我很好奇的是为什么 'su' 需要等待。 'cat' 重定向是否可能只是删除文件并使用新输出重新创建它,或者这只是锁定机制在命令之间不一致的情况?

编辑:由于提出问题,我在Java应用程序中添加了一些写语句,因此程序的结构如下:

Acquire Java Lock on /etc/passwd
IO-Redirect with a small change to /etc/passwd
Append some text to /etc/passwd in the Java application

所有这些信息都反映在更新的 /etc/passwd 中,因此看来 IO-Redirection 并不是简单地删除文件。因此,为什么 'su' 和 '>' (可能还有许多其他东西)之间存在差异?

【问题讨论】:

    标签: java unix aix io-redirection su


    【解决方案1】:

    UNIX 上的文件锁定是建议性的,不是强制性的。也就是说,锁完全独立于任何试图读取或写入文件的人,并且对任何人都没有影响。它只与试图获取锁的其他程序交互。

    由于cat 和重定向不会尝试锁定文件,因此锁定对它们没有影响。另一方面,su 在读取 /etc/passwd 之前将其锁定,因此您持有锁的程序会导致它等待(获取锁)直到您释放它。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2014-03-30
      • 1970-01-01
      • 1970-01-01
      • 2023-03-14
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多