从ln的联机帮助页：
-d, -F, --directory
allow the superuser to attempt to hard link directories (note: will
probably fail due to system restrictions, even for the superuser)
是否有任何文件系统驱动程序实际上允许这样做，或者是唯一的选择mount --bind <src> <dest>？或者这种行为是否在到达特定于文件系统的驱动程序之前就被内核阻止了？
注意：我实际上并不打算在任何机器上执行此操作，只是出于好奇。
所以，我认为这将是一个非常简单的定位：一个服务/内核模块，当内核注意到用户空间内存不足时，会触发一些操作（例如，将进程列表转储到文件中，ping 某个网络端点，等等) 在具有自己专用内存的进程中（因此它不会失败 fork() 或遭受任何其他常见的 OOM 问题）。
我发现了OOM 杀手，我认为它很有用，但它并没有真正做我需要做的事情。
理想情况下，如果我的内存不足，我想知道原因。我想我可以编写自己的程序，在启动时运行并使用固定数量的内存，然后仅在内核通知内存不足时才执行操作，但这带来了它自己的问题......
甚至有一个系统调用被告知类似的事情吗？一种对内核说“嘿，当我们只剩下 128 MB 内存时叫醒我”的方法？
我在网上和这里搜索，但没有找到任何符合该描述的内容。似乎大多数人在时间延迟上使用轮询，但明显的问题是它使您不太可能知道是哪个进程导致了问题。
安装 Debian 8 后，我开始在 /bin 周围闲逛（因为我总是不会这样做），我注意到ls并vdir共享，不仅是相同的联机帮助页（行除外whatis），而且编译大小完全相同。它们唯一没有共同点的是 inode 编号（这似乎效率低下，但很重要）。
这有什么原因吗？有什么历史先例？为什么我们要两者兼得？
我vdir在今天之前从未听说过，所以它不可能非常普遍，而且似乎简单地拥有vdir一个ls使用正确参数调用的脚本应该很容易。
以下内容在 bash 中不会产生任何内容：
while true ; do upower -d ; sleep 1 ; done | grep percentage | uniq
我发现这个链中的最后一个或什至倒数第二个程序是什么并不重要。倒数第二个程序总是产生预期的输出，而最后一个程序总是无法产生任何东西。
如果我将 while 循环包装在子外壳中（通过( while ... done )），或者将除最后一个命令之外的所有内容都包装在子外壳中并通过管道传输到最后一个命令中，这似乎也无关紧要。
我对这种行为深感困惑。
...由于阻塞读取和写入以及 while 循环并不总是产生输出的事实，在链中存在某种 I/O 死锁。但是，另一方面，我以前做过很多次这种事情，没有问题。另外，如果那样的话，while循环和下一个命令之间不就存在问题了吗？所以我很困惑。如果没有其他人可以复制，将提供 bash 版本信息。
这行代码的重点是打印电池百分比的每个变化，但只打印新的电池电量。它使用轮询。我想我可以通过简单地运行获得相同的行为
upower --monitor-detail | grep percentage | uniq
但这是一次性的事情，我不打算在上面花费超过 5 秒的思考时间，直到上面开始失败。在这一点上，它变成了一个有趣的问题。另外，我不知道 monitor-detail 是否只是在幕后进行轮询（而且我没有运行 strace 来检查）。
编辑：显然，上面的--monitor-detail版本也没有产生任何东西（或者，至少，它似乎。轮询/更新频率非常低，所以我可能等待的时间不够长。虽然我知道我等了足够长的时间原来的问题）。现在我非常非常困惑。我想我应该运行那个 strace ......