Another daemon for managing control groups

When you start services at boot-up, then you need to start them in the right order, possibly waiting for devices to show up first. Here's an example: for each block device that needs to be mounted, we first need to wait until it shows up (this is because device management is entirely hotpluggy and dynamic these days), then we need to run the "fsck" service on it. Then we need to mount it. Finally, after we did that for all file systems listed in /etc/fstab we can go on to the next step, and start the next service, for example apache, which expects all those file systems to have shown up, fscked, and mounted. So there you have the connection between device and service management.

Now, if you start services like apache and mysql, then in a large part of cases you want to resource manage them. Actually, without even configuring something explicitly it is highly preferable if apache and mysql get roughly the same amount of resources, even though apache runs tons of worker and CGI processes, and mysql only very few worker threads. Because if you don't even that out then apache might starve mysql to death even though it needs its service. Sooo. there you have the connection between service and cgroup management: for the services you start you need to set up cgroups and contain the service processes in them, racefreely, and unconditionally. So there you have the connection between cgroup and service management.

In addition there's also the third connection: between device and cgroup management. That's because for a number of cgroup properties you need to configure major/minor device ids. For example the "blkio" and "devices" controllers rely on that to set resource or access constraints per device. Now, major/minor assignment by the kernel is pretty much dynamic these days. Basically, before a device has shown up you cannot know which major/minor it will get. A cgroup manager which gets told to configure a 5MB/s bandwidth limit for a specific cgroup for a specific device hence needs to refresh the list of limits in the cgroup each time any device in that list pops up or is removed. Since admins probably prefer specifiying their devices with the stable per-uuid or per-path symlinks that udev creates the cgroup manager hence needs to be integrated with udev.

So there you have it: there's a connection between all three areas, in all directions.