이 오류의 원인: udevd [PID]: inotify_add_watch(6, /dev/sda, 10) 실패: 작업이 허용되지 않습니다.

Ubuntu 12.04: 시작 시 데몬을 비활성화하는 방법

데비안 버그 보고서 로그 - #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의 가명(!)인 것으로 알고 있습니다. 그 중 하나 또는 누군가가 그의 글쓰기 스타일과 문제에 대한 그의 입장에 맞는 훌륭한 흉내를 냈습니다. :-).

udev아마도 LXC에 더 익숙한 사람이라면 LXC가 기대하는 조합이 무엇인지 , 그리고 유용한 작업을 수행하기 위해 LXC 설정이 무엇을 하는지 정확히 알 것입니다 . 어떤 조건에서 그러한 경고 메시지가 생성될 수 있는지 알아보세요. 위의 링크는 원래 Ubuntu 12.04 릴리스가 괜찮을 것이라고 주장하면서 Ubuntu의 날짜 범위를 제공합니다. 그러나 허위 경고를 발령했는지 여부는 밝히지 않았습니다. (이 작업을 수행하는 최초의 소프트웨어는 아닙니다 :-))

장점이 무엇이든 간에, 당신이 있는 한,아니요LXC 내에서 물리적 장치에 액세스해야 하는 경우 udev를 비활성화하는 것이 udev 경고를 표시하지 않는 쉬운 방법인 것 같습니다. "사람들이 장치 네임스페이스가 어떻게 작동하는지 파악하기를 기다리는 동안". LXC 개발자들은 "이것은 이상적이지 않다"고 언급했습니다 :-). 그것은 2013년이었고, 아직 장치 네임스페이스가 없었습니다(Linux v4.20 기준).

다음 관련 설명은 "우리의 기본 구성을 사용하면 udev가 장치 노드를 생성할 수 있지만 구성에서 허용되는 액세스 노드만 허용됩니다." 이러한 의미에서 LXC는 LXC가 의도한 대로 작동합니다. node /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