Getting invalid request when querying co-mounted cgroups

Bug #1438345 reported by Stéphane Graber
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cgmanager (Ubuntu)
Fix Released
Critical
Serge Hallyn

Bug Description

root@autopkgtest:~# cgm listcontrollers
blkio
cpu,cpuacct
cpuset
devices
freezer
hugetlb
memory
net_cls,net_prio
perf_event
name=systemd

root@autopkgtest:~# cgm gettasks cpu,cpuacct .
call to cgmanager_get_tasks_sync failed: invalid request

root@autopkgtest:~# cgm gettasks cpu .
5369
5432
5433
5452
5453
16921
16934
16935
23051

root@autopkgtest:~# cgmanager --version
cgmanager 0.36

This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
root@autopkgtest:~# dpkg -l | grep cgmanager
ii cgmanager 0.36-2ubuntu3 amd64 Central cgroup manager daemon
ii libcgmanager0:amd64 0.36-2ubuntu3 amd64 Central cgroup manager daemon (client library)
root@autopkgtest:~#

Revision history for this message
Stéphane Graber (stgraber) wrote :

This bug was caught by the lxcfs testsuite and indeed breaks lxcfs for any container task which attempts to access the co-mounted cgroups (liked systemd).

Changed in cgmanager (Ubuntu):
status: New → Triaged
importance: Undecided → Critical
assignee: nobody → Serge Hallyn (serge-hallyn)
Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 1438345] [NEW] Getting invalid request when querying co-mounted cgroups

The bug fixed in 0.36-2ubuntu3 had to do with an actual cgmanager
crash due to mis-handling of co-mounted containers in methods which
were supposed to handle multiple controllers in one call.

gettasks is not such a method - it only takes a single controller.
So the question here is whether we

(a) tell callers they must ensure no ',' (or "all") in controllers passed
to gettasks

(b) uglify all calls which currently do not handle multiple controllers
so as to handle multiple controllers

(c) uglify all calls which currently do no thandle multiple controllers, just
enough to check whether all controllers passed in are co-mounted.

Note that 'gettasksrecursive' will handle "cpu,cpuacct" the way you
expect.

I suspect (c) will be the sanest answer here, although I don't like it.
The "correct" but probably not-sufficient answer is (a).

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Quoting Stéphane Graber (<email address hidden>):
> This bug was caught by the lxcfs testsuite and indeed breaks lxcfs for

i see - perhaps it is lxcfs which should be fixed. then. Not sure yet,
but adding bugtask in any case:

Revision history for this message
Stéphane Graber (stgraber) wrote :

Perhaps though it does seem odd to me that listcontrollers would return names that can't be used as the controller argument in subsequent calls.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 1438345] Re: Getting invalid request when querying co-mounted cgroups

Quoting Stéphane Graber (<email address hidden>):
> Perhaps though it does seem odd to me that listcontrollers would return
> names that can't be used as the controller argument in subsequent calls.

Good point. So we should simply be able to call
do_prune_comounts(controllers) in the affected functions.

no longer affects: lxcfs (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cgmanager - 0.36-2ubuntu4

---------------
cgmanager (0.36-2ubuntu4) vivid; urgency=medium

  * Handle user passing in a list of co-mounted controllers (LP: #1438345)
 -- Serge Hallyn <email address hidden> Thu, 02 Apr 2015 09:30:10 -0500

Changed in cgmanager (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

FYI, this bug was mentioned by accident in the Apport security update changelog. The actual bug for apport is #1438758.

Revision history for this message
Stéphane Graber (stgraber) wrote :

Oops, wrong copy/paste when I prepared the debdiffs, sorry about that ;)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.