Several problems in cgclear

Bug #827279 reported by Jamie Strandboge
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
libcgroup (Ubuntu)
In Progress
Medium
Unassigned
Nominated for Lucid by Serge Hallyn
Nominated for Maverick by Serge Hallyn
Nominated for Natty by Serge Hallyn

Bug Description

On an up to date Oneiric, I tried to start a virtual machine via libvirt and got:
error: Failed to start domain sec-hardy-amd64
error: Unable to create cgroup for sec-hardy-amd64: No such file or directory

This may or may not be bug #795905, but since I was only playing around with cgroups and don't actually use them, I decided to simply remove the cgroup packages, so I did:
$ sudo apt-get remove --purge libcgroup1
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  cgroup-bin* libcgroup1*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 487 kB disk space will be freed.
Do you want to continue [Y/n]? y
(Reading database ... 289248 files and directories currently installed.)
Removing cgroup-bin ...
cgred stop/waiting
stop: Job failed while stopping
invoke-rc.d: initscript cgconfig, action "stop" failed.
dpkg: error processing cgroup-bin (--purge):
 subprocess installed pre-removal script returned error exit status 1
cgconfig start/running
libvirt-cgred-wait stop/waiting
dpkg: libcgroup1: dependency problems, but removing anyway as you requested:
 cgroup-bin depends on libcgroup1.
Removing libcgroup1 ...
Purging configuration files for libcgroup1 ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Errors were encountered while processing:
 cgroup-bin
E: Sub-process /usr/bin/dpkg returned an error code (1)

I then had to perform the following two times (the first fails similarly as above):
$ sudo apt-get remove --purge cgroup-bin

Once I removed cgroup-bin, I still had to stop then start libvirt to use my VMs with:
$ sudo stop libvirt-bin
$ sudo start libvirt-bin

Tags: patch oneiric
description: updated
summary: - Failed to uninstall cgroup-bin
+ Several problems with maintainer scripts when uninstalling
Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: Several problems with maintainer scripts when uninstalling

Thanks, Jamie. Your original problem appears to be a dup of bug 827538 in libvirt, but the purge failures of course must be fixed here.

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

marking confirmed as I just reproduced.

Changed in libcgroup (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

It looks like a failure in /usr/sbin/cgclear, which is hanging.

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

There are at least two problems in cgclear. One is that it bails if
moving a task to root cgroup returns 'no such process'. But of course
that's just a race condition (task has exited) which should be ignored.

When that is fixed I have also seen:
rmdir("/sys/fs/cgroup/memory/./sysdefault/") = -1 EBUSY (Device or resource busy)

Which is absolutely wrong. sysdefault is a directory and can't be
umounted. I have not yet found the root cause for this.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :
summary: - Several problems with maintainer scripts when uninstalling
+ Several problems in cgclear
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

(Changed the title as maintainer scripts are unrelated AFAICT)
(Note also that having to restart libvirt-bin at the end of it all is due solely to the libvirt bug)

Changed in libcgroup (Ubuntu):
status: Confirmed → In Progress
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

While the patch seems generally ok, I am not familiar with cgroup code and would prefer if an upstream bug was filed with their ACK before applying the patch. Specifically, these bits:
+- if (ret < 0)
+- break;
++ if (ret < 0) {
++ if (errno != ESRCH)
++ break;
++ // the task just went away, ignore it
++ ret = 0;
++ continue;
++ }

seems to be a pretty big departure from the original where we are breaking only on ESRCH instead of all errors.

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

Note that we are only *not* breaking on ESRCH.

Assigning to jbernard as the most viable upstream (being the Debian maintainer). Jon, if you don't have time to deal with this, please re-assign to me and I'll open the debian bug and send a flare over to the original authors.

Changed in libcgroup (Ubuntu):
assignee: nobody → Jon Bernard (jbernard)
tags: added: patch
Jon Bernard (jbernard)
Changed in libcgroup (Ubuntu):
assignee: Jon Bernard (jbernard) → nobody
Ken Sharp (kennybobs)
tags: added: oneiric
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.