监视发送到/ dev / null的内容？

只是为了好玩：
是否有办法监视/捕获/转储正在写入的内容/dev/null？

如果需要的话，在Debian或FreeBSD上，也欢迎使用任何其他特定于操作系统的解决方案。

monitoring devices open-files

— 阿里
source

可能，但是正如答案和评论所描述的那样，这不是一个好主意。

— 沙杜尔

@Shadur：可能有不好的解决方案，但这并不会使这个想法变得毫无趣味或一个坏想法。

— jlliagre 2012年

的确，我只是找到了这个问题，因为我正在考虑对许多捕获到的内容进行分析的结果/dev/null。我不想自己做研究，但我想阅读结果。（从本质上来说，“

— 仔细

Answers:

制作/dev/null命名管道可能是最简单的方法。请注意，某些程序（sshd例如）在发现它不是特殊文件时（例如，它们可能会从中读取/dev/null，期望其返回EOF），将异常运行或无法执行。

# Remove special file, create FIFO and read from it
rm /dev/null && mkfifo -m622 /dev/null && tail -f /dev/null
# Remove FIFO, recreate special file
rm /dev/null && mknod -m666 /dev/null c 1 3

这应该在所有Linux发行版和所有主要的BSD上都有效。

— 克里斯·唐
source

要注意的一件事是，如果tail失败，则由于管道缓冲区已满，很多程序可能会失败。

— Arcege'2

从中读取的程序/dev/null不会像这样。

— 吉尔斯（Gilles）'所以别再邪恶了'

@吉尔斯-的确如此，因此请注意。

— 克里斯·

@Ali是的。No magic是UNIX哲学中的指导原则。

— phihag 2012年

Ahem /dev/null 是魔术，mknod /dev/null c 1 3是调用它的魔术公式。（而且您需要超能力……）

— 斯特凡·吉梅内斯

有一次，我发现了的/ dev / null的不硬的方式必须是一个特殊的dev文件。很久以前，正在使用的Ultrix系统上的/ dev / null被删除，因此，下次程序重定向到/ dev / null时，它最终变成了包含该程序输出的普通文件。（我认为这不是“没有这样的文件或目录”，这意味着当我们试图弄清正在发生什么时，我们会做cat /dev/null并被告知no such file or directory哪个让我们感到困惑。）

因此，我的建议是将其替换为命名管道，然后将程序附加到将读取并监视它的管道。

— 保罗·汤姆林
source

许多程序还依赖于/dev/null在read（cat /dev/null > foo）上始终返回0字节。具有/dev/null内容的常规文件会破坏这种期望。

— Arcege'2

是的，这就是我们发现它的方式。程序原本期望没有输入并得到大量输入，再加上/ dev /已被填满。

— Paul Tomblin'2

我想到了一个想法，其中/ dev / null可以是文件描述符的符号链接，但是具有添加代码机制来确定是读取还是写入操作，然后如果读取了它，则实际上应该从分别创建的/ dev / actualnull中读取mknod，如果已写入，请记下调用程序，并尝试记录/计数以分析使用/ dev / null进行写入的程序。我想这会在性能上付出很多代价。我猜这是不实际的，因为大多数shell程序或代码无论如何都使用重定向。可能是inotify可以用来监视/ dev / null的使用吗？或重写处理1：3设备的内核代码，再次编译并重新安装，可以进行实验。

— 尼基尔·穆利（Nikhil Mulley）
source

仍然存在一些问题，我尝试做这样的事情（不是内核中的，而是通过允许从另一个文件读取并/dev/null从守护程序进行控制来透明地执行），sshd但仍然抱怨并且无法启动。

— 克里斯·

hmm ..有趣的是从守护程序控制/ dev / null。我认为大多数程序只想将/ dev / null用作另一个文件，而将/ dev / null的重要性和语义留给系统使用。

— Nikhil Mulley 2012年

好吧，sshd（至少，如Debian Squeeze所包装的那样）抱怨它sshd: cannot create /dev/null是否是最常见的实现。

— 克里斯·