Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
  • This project
    • Loading...
  • Sign in / Register
L
lxc
  • Project
    • Overview
    • Details
    • Activity
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 0
    • Issues 0
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Chen Yisong
  • lxc
  • Repository

Switch branch/tag
  • lxc
  • doc
  • lxc.container.conf.sgml.in
Find file
BlameHistoryPermalink
  • Shukui Yang's avatar
    confile: add "force" to cgroup:{mixed,ro,rw} · 64598005
    Shukui Yang authored Feb 15, 2018
    This lets users specify
    
            lxc.mount.auto = cgroup:mixed:force
    or
            lxc.mount.auto = cgroup:ro:force
    or
            lxc.mount.auto = cgroup:rw:force
    
    When cgroup namespaces are supported LXC will not mount cgroups for the
    container since it assumes that the init system will mount cgroups itself if it
    wants to. This assumption already broke when users wanted to run containers
    without CAP_SYS_ADMIN. For example, systemd based containers wouldn't start
    since systemd needs to mount cgroups (named systemd hierarchy for legacy
    cgroups and the unified hierarchy for unified cgroups) to track processes. This
    problem was solved by detecting whether the container had CAP_SYS_ADMIN. If it
    didn't we performed the cgroup mounts for it.
    However, there are more cases when we should be able to mount cgroups for the
    container when cgroup namespaces are supported:
    - init systems not mounting cgroups themselves:
      A init system that doesn't mount cgroups would not have cgroups available
      especially when combined with custom LSM profiles to prevent cgroup
      {u}mount()ing inside containers.
    - application containers:
      Application containers will usually not mount by cgroups themselves.
    - read-only cgroups:
      It is useful to be able to mount cgroups read-only to e.g. prevent
      changing cgroup limits from inside the container while at the same time
      allowing the applications to perform introspection on their own cgroups. This
      again is mostly useful for application containers. System containers running
      systemd will usually not work correctly when cgroups are mounted read-only.
    To be fair, all of those use-cases could be covered by custom hooks or
    lxc.mount.entry entries but exposing it through lxc.mount.auto takes care of
    setting correct mount options and adding the necessary logic to e.g. mount
    filesystem read-only correctly.
    
    Currently we only extend this to cgroup:{mixed,ro,rw} but technically there's
    no reason not to enable the same behavior for cgroup-full:{mixed,ro,rw} as
    well. If someone requests this we can simply treat it as a bug and add "force"
    for cgroup-full.
    
    Replaces #2136.
    Signed-off-by: 's avatarShukui Yang <yangshukui@huawei.com>
    Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    64598005
lxc.container.conf.sgml.in 75.4 KB
EditWeb IDE
×

Replace lxc.container.conf.sgml.in

Attach a file by drag & drop or click to upload


Cancel
A new branch will be created in your fork and a new merge request will be started.