cgconfig gets confused with /cgroups fstab entry

[Scott Moser]

Following previous documentation I'd seen in the natty time frame, and are also documented at lxc upstream (http://lxc.teegra.net/), I had a line like the following in /etc/fstab:
  none /cgroups cgroup defaults 0 0

Then, I found out about cgroup-bin, and thought that looked like the "supported" way to get cgroups mounted.
So, I did:
 $ sudo apt-get install cgroup-bin

That ended with:
  Setting up libcgroup1 (0.37.1-1ubuntu7) ...
  Setting up cgroup-bin (0.37.1-1ubuntu7) ...
  start: Job failed to start
  invoke-rc.d: initscript cgconfig, action "start" failed.
  dpkg: error processing cgroup-bin (--configure):
   subprocess installed post-installation script returned error exit status 1
  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)

Then, an 'apt-get -f install' showed:
  Setting up cgroup-bin (0.37.1-1ubuntu7) ...
  cgconfig start/running

So I thought all was well, and some strange transient error.

After reboot, though, I come into the following state:
  $ grep cgroup /proc/mounts
  $ sudo status cgconfig
  $ grep cgconfig /var/log/kern.log
  Oct 6 17:21:53 server-2206 kernel: [ 33.803611] init: cgconfig pre-start process (697) terminated with status 3

Then, trying to fix the situation shows the issue:
  $ sudo mount /cgroup
  none /cgroup cgroup rw,relatime,perf_event,blkio,net_cls,freezer,devices,memory,cpuacct,cpu,cpuset 0 0
  $ sudo start cgconfig
  $ grep cgroup /proc/mounts
  <empty>
  $ sudo mount -av
  mount: proc already mounted on /proc
  mount: /dev/vdb already mounted on /mnt
  mount: none already mounted on /cgroup
  nothing was mounted
 $ ls /cgroup/
 <empty>
  $ grep cgroup /proc/mounts
  <empty>

Basically, if you have cgroups mounted, 'start cgconfig' will fail, and unmount your existing cgroup mount point, leaving you broken, and even 'mount' is confused by the state of the world (it thinks /cgroup was already mounted, when it is not). This will happen on every boot.

[1] http://lxc.teegra.net/

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: cgroup-bin 0.37.1-1ubuntu7
ProcVersionSignature: User Name 3.0.0-12.19-virtual 3.0.4
Uname: Linux 3.0.0-12-virtual i686
ApportVersion: 1.23-0ubuntu1
Architecture: i386
Date: Thu Oct 6 17:06:28 2011
Ec2AMI: ami-000000ad
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: libcgroup
UpgradeStatus: No upgrade log present (probably fresh install)

[Scott Moser (smoser)]

I'm not sure what ends up doing the unclean unmount of /cgroup when you try to start cgconfig, but an strace of
  /usr/sbin/cgconfigparser -l /etc/cgconfig.conf
shows:
stat64("/sys/fs//cgroup/cpu", 0xbfb057c0) = -1 ENOENT (No such file or directory)
mkdir("/sys", 0775) = -1 EEXIST (File exists)
mkdir("/sys/fs", 0775) = -1 EEXIST (File exists)
mkdir("/sys/fs//cgroup", 0775) = -1 EEXIST (File exists)
mkdir("/sys/fs//cgroup/cpu", 0775) = 0
mount("cgroup", "/sys/fs//cgroup/cpu", "cgroup", 0, "cpu") = -1 EBUSY (Device or resource busy)
oldumount("/sys/fs//cgroup/cpu") = -1 EINVAL (Invalid argument)
rmdir("/sys/fs//cgroup/cpu") = 0
oldumount("/sys/fs/cgroup/cpuacct") = -1 ENOENT (No such file or directory)
rmdir("/sys/fs/cgroup/cpuacct") = -1 ENOENT (No such file or directory)
oldumount("/sys/fs/cgroup/devices") = -1 ENOENT (No such file or directory)
rmdir("/sys/fs/cgroup/devices") = -1 ENOENT (No such file or directory)
oldumount("/sys/fs/cgroup/memory") = -1 ENOENT (No such file or directory)
rmdir("/sys/fs/cgroup/memory") = -1 ENOENT (No such file or directory)
oldumount("/sys/fs/cgroup/freezer") = -1 ENOENT (No such file or directory)
rmdir("/sys/fs/cgroup/freezer") = -1 ENOENT (No such file or directory)

[Serge Hallyn (serge-hallyn)]

This is happening because you can't have multiple mounts of cgroups with different compositions.

Ideally I'd say the cgroup-bin postinst should forcibly umount any other /cgroup mounts, but if, as in your case, the user had cgroup in his fstab, that would continue to cause troubles.

Perhaps the package postinst should simply provide a more meaningful warning message if it finds cgroups already mounted, and ask the user to resolve the situation?

[Serge Hallyn (serge-hallyn)]

The analogous bug was fixed for cgroup-lite by having its upstart job (through cgroup-lite.cgroups-mount) fail to run, and log to syslog, if a cgroup entry is in fstab.

cgroup-bin.cgconfig.upstart should do the same.