☰

此错误的来源： udevd [ PID ]: inotify_add_watch(6, /dev/sda, 10) 失败：不允许操作

tag-icon • tag-icon linux logs syslog inotify
此错误的来源： udevd [ PID ]: inotify_add_watch(6, /dev/sda, 10) 失败：不允许操作

我们的系统日志中有这样的日志：

udevd [ PID ]: inotify_add_watch(6, /dev/sda, 10) failed: operation not permitted

为什么我们会收到此错误以及如何解决它？

我们的环境：Ubuntu 12.04； LXC；我们在容器内运行；我不确定 SELinux（我没有访问权限），但它没有启用。

答案1

Ubuntu12.04：如何在启动时禁用守护进程

Debian Bug 报告日志 - #620921 udev：请检测 lxc，不要尝试从那里启动

乍一看，容器中支持 udev 事件。但为了优化，我建议不要使用它，因为它会触发所有容器中的事件。

如果以上内容不清楚，我建议用火杀死它。通常，在udev容器内部甚至考虑触摸等都是不希望的sda。通常不会有任何事物你希望 udev 做的事情。

阅读以下内容，您可能会猜到我的答案是遵守systemd党派路线:-)。显然 LXC 至少在某个时候有一些不同的观点：https://stgraber.org/2013/12/21/lxc-1-0-your-second-container/#comments

systemd我相信评论者“wwwwww”是主角 Lennart Poettering的化名（！） 。要么是这样，要么有人做了一个很好的模仿，匹配他的写作风格和他在这个问题上的立场:-)。

也许更熟悉 LXC 的人会确切地知道 LXC 期望哪些组合udev和 LXC 设置可以做任何有用的事情。以及什么条件可能会生成这样的警告消息。上面的链接提供了 Ubuntu 的日期范围，声称原始的 Ubuntu 12.04 版本应该没问题。然而，它没有说明它是否发出任何虚假警告。 （这不是第一个这样做的软件:-)）

无论有什么优点，只要你不如果需要从 LXC 内部访问任何物理设备，禁用 udev 似乎是避免看到任何 udev 警告的简单方法。 “当我们等待人们弄清楚设备命名空间应该如何工作时”。 LXC 开发人员提到“这远非理想”:-)。那是在 2013 年，仍然没有设备命名空间（截至 Linux v4.20）。

下一个相关评论似乎是“我们的默认配置将让 udev 创建设备节点，但仅访问配置中允许的节点。”从这个意义上说，你的 LXC 正在按照 LXC 的预期工作：它允许你创建一个设备节点/dev/sda，但不允许你访问它。

我不知道为什么您的udev创建/dev/sda（大概）不会抱怨无法blkid在其上运行，但会抱怨无法观看它。

内核（从 v4.20 开始）不提供设备隔离。设备没有命名空间。例如，与允许隔离网络接口的网络命名空间相比。有关可以隔离的命名空间的列表，请查看man 7 namespaces或者man 2 clone。

如果您好奇什么是有原则的容器运行时能这样做，答案是它可以禁用对所有设备的访问（除了一些虚拟设备，如/dev/null、/dev/pts/*等）。我更熟悉systemd-nspawn（及其文档）。至少在 cgroups v1 中，nspawn 使用设备控制组来禁用对设备的访问。 cgroups v2 最终获得了同等的功能。同时，nspawn 会阻止你创造一个设备节点，使用seccomp()，效果很好。当然，这意味着您必须相信容器文件系统映像不包含任何“错误”的设备节点，因此 cgroup 解决方案更好。

Current检测到如果已以只读方式安装，systemd-udevd.service则不应运行。/sys

相关内容