cgconfig upstart job should start earlier and mount all available cgroup types by default
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libcgroup (Ubuntu) |
Confirmed
|
High
|
Unassigned |
Bug Description
ubuntu 12.04 LTS, amd64
cgroup-bin 0.37.1-1ubuntu10
1. cgconfig upstart job should start earlier.
/etc/init/
start on runlevel [2345]
but should contain this (like cgroup-lite.conf does)
start on mounted MOUNTPOINT=/sys
Why it's needed? Imagine, I want cupsd to start with memory limit (cgroup called daemon-cups). To do this I edited configs:
/etc/cgconfig.conf
group daemon-cups {
memory {
memory.
}
}
/etc/cgrules.conf
root:
Now, after computer rebooted, I can see that daemon-cups cgroup is created but cupsd isn't in daemon-cups cgroup tasks. It appears there only after:
service cups restart
That's because cups service started earlier than cgred service (and cgred service starts on started cgconfig).
Than imagine what if lxc will somehow start earlier than cgconfig? No, it won't start at all. So, I think this should be fixed.
2. cgconfig should mount all available cgroup types by default.
Default /etc/cgconfig.conf contains these:
mount {
cpu = /sys/fs/
cpuacct = /sys/fs/
devices = /sys/fs/
memory = /sys/fs/
freezer = /sys/fs/
}
What if I want to use LXC on the same machine and one container's config contains something like this:
lxc.cgroup.
Container will not start, because this cgroup type is not mounted by default with cgroup-bin package.
I think, the best way to fix this is to mount available cgroup fsystems via upstart job (the way cgroup-lite does it). Another way is to change default /etc/cgconfig.conf (add mountpoints). But I would prefer the first solution (it's kernel independent).
3. After all these I'm asking you what is the reason of separation cgroup-bin and cgroup-lite into different packages. Why not to just disable cgrulesengd, cgconfigparser by default (using /etc/default somehow)? For example, if I'm using LXC, I will likely be using cgget/cgset or something. And even if won't be using it what's wrong with that these binaries are in my /usr/bin (100Kb)?
P.S. cgconfig.conf : cpu = /sys/fs/
Thanks, hope it'll be fixed in LTS.
Changed in libcgroup (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → High |
tags: | added: amd64 precise |
Thanks for submitting this bug. I agree with your analysis.
The reason for the separate cgroup-lite package is that simply disabling the broken libcgroup tools by default, but still installing them, would (a) be harder to get into main (and not justifiable in my opinion) and (b) still look like an endorsement of the tools, when we know they are broken (for instance when used with libvirt). Plenty of new users would re-enable them, break libvirt, and file bugs.
If you are using lxc and wish to manipulate cgroups with a tool, the preferred way would be to use the lxc-cgroup command. I do believe (having just checked) there is a bug in lxc-cgroup in precise, but that should be fixed and should be a simple fix.