What the !!?? is this?

[viking777]

As of today I have just noticed that I have a new mount point created on every boot:

Code: Select all

cgroup on /dev/cgroup/cpu type cgroup (rw,cpu)

The address listed is populated with folders and files which, although I can open them easily enough and they are written in plain English, they don't contain anything that I can understand.

It doesn't come from fstab, and as far as I can tell it wasn't there yesterday.

So what is this and why has it suddenly appeared?

This is the definition of a cgroup from the Arch wiki:

cgroups (aka control groups) is a Linux kernel feature to limit, police and account the resource usage of certain processes (actually process groups). Compared to other approaches like the 'nice' command or /etc/security/limits.conf, cgroups are infinitely more flexible.

But I haven't created anything like that and probably wouldn't know what to do with it if I had.

I did update to gnome3 yesterday - has it got something to do with that? Or I guess it is possible, since I don't check the 'mount' command every day that it could have been there for some time and I just haven't noticed it.

I think I might be a bit happier if I knew that other people have this mount created as well.

All information gratefully received.

PS. This is on LMDE 64bit tracking testing. I haven't looked at anything else yet, I will do so immediately after posting this topic.

[Oscar799]

Moved here from Other Topics

[Anakinholland]

odd that it appeared only yesterday, and that is has it's own mount-point, but nothing too worry about

I've had this on my work laptop since the release of RHEL6, late last year. If you don't modify anything it will be purely administrative.

I didn't go in-depth yet, but if you look at for instance the file (they're pipe-files btw, you cannot copy them, etc, just like on /proc) /cgroup/cpuacct/cpuacct.usage , you will see (i think) the amount of CPU-cycles that have been used in total. In the file /cgroup/memory/memory.usage_in_bytes you'll find the memory-usage.

If you look at the same files in sub-directory libvirt you will see the amount of CPU-cycles and memory used by KVM virtual machines, which at the moment are both 0 overhere as there's no virtual machine running.

This data it is fairly easy to create a customer-bill based on actual usage, etc, etc.

I hope I made sense?

[viking777]

odd that it appeared only yesterday, and that is has it's own mount-point, but nothing too worry about

I've had this on my work laptop since the release of RHEL6, late last year. If you don't modify anything it will be purely administrative.

I didn't go in-depth yet, but if you look at for instance the file (they're pipe-files btw, you cannot copy them, etc, just like on /proc) /cgroup/cpuacct/cpuacct.usage , you will see (i think) the amount of CPU-cycles that have been used in total. In the file /cgroup/memory/memory.usage_in_bytes you'll find the memory-usage.

If you look at the same files in sub-directory libvirt you will see the amount of CPU-cycles and memory used by KVM virtual machines, which at the moment are both 0 overhere as there's no virtual machine running.

This data it is fairly easy to create a customer-bill based on actual usage, etc, etc.

I hope I made sense?

Indeed you did make sense, and thank you for the prompt reply, it is good to know that I am not alone. As for when it occurred, I don't say it was definitely yesterday, it is only that yesterday I did a major upgrade (gnome3), and today was when I first noticed it and I just linked the two together, but it might have been there for some while.

So we know it occurs on Red Hat, and I have got it on LMDE64 but not on any of the other 4 distros I am running.

Any other LMDE or MInt users got this?

[zerozero]

well, it's here, in the same testing system as you:

Code: Select all

mount
/dev/sda5 on / type ext4 (rw,errors=remount-ro,commit=0)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,size=5242880,mode=755,size=5242880,mode=755)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=755,size=10%,mode=755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,size=20%,mode=1777,size=20%,mode=1777)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620,gid=5,mode=620)
/dev/sdb1 on /media/usb0 type ext3 (rw,noexec,nodev,sync,noatime,nodiratime,errors=continue,barrier=0,data=ordered,commit=0)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
cgroup on /dev/cgroup/cpu type cgroup (rw,cpu)


Edit:
and it's also on my xfce install tracking incoming (and with no updates or ages)

Code: Select all

mount
/dev/sda6 on / type ext4 (rw,errors=remount-ro,commit=0)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,size=5242880,mode=755,size=5242880,mode=755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /var/run/shm type tmpfs (rw,nosuid,nodev,size=20%,mode=1777,size=20%,mode=1777)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620,gid=5,mode=620)
tmpfs on /var/run type tmpfs (rw,noexec,nosuid,relatime,size=406044k,mode=755)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
cgroup on /dev/cgroup/cpu type cgroup (rw,cpu)

[altair4]

Did a google search on "cgroups" and found this: http://hydra.geht.net/tino/english/faq/ ... e/cgroups/

What are Cgroups?
Cgroups can be used to improve the way Linux schedules time to processes. Instead of scheduling the time by each process, the time will be scheduled first on the cgroups and each time which is given to a cgroup then is distributed along to all processes which are in the cgroup.

Cgroups are best used such, that only a few Cgroups are active in parallel, and that the majority of tasks are bound to a proper Cgroup.

[viking777]

zerozero/altair4 thank you for the replies. The link that altair found was better than the one I located, but is obviously not relevant to debian as of now. The link mentions /etc/init.d/cgred but that doesn't exist. It suggests editing /etc/cgconfig.conf but that doesn't exist either, neither does /etc/cgrules.conf which was also mentioned.

Personally I don't believe that this particular technology has any relevance to a home user and therefore is nothing but a drain on the very resources it is trying to protect. All I need to know about it is how to disable it for good, so if anyone has any ideas on that please let me know. Or I may be wrong, and this piece of code is going to revolutionise my computing life, then let me know that as well if it is the case.

Another thing I would love to know the answer to is when this was introduced to Debian exactly. Obviously it has been around in Red Hat for a while as Anakinholland's post suggests, but in LMDE was it part of the Gnome3 update I did yesterday, or has it taken me a long time to notice it?

[miffojon]

I've been wondering what this was in my /etc/rc.local:

mkdir -p /dev/cgroup/cpu
mount -t cgroup cgroup /dev/cgroup/cpu -o cpu
mkdir -m 0777 /dev/cgroup/cpu/user
echo "/usr/local/sbin/cgroup_clean" > /dev/cgroup/cpu/release_agent

Now I know, thank you all!

Will remove and see what happens...

[viking777]

I've been wondering what this was in my /etc/rc.local:

mkdir -p /dev/cgroup/cpu
mount -t cgroup cgroup /dev/cgroup/cpu -o cpu
mkdir -m 0777 /dev/cgroup/cpu/user
echo "/usr/local/sbin/cgroup_clean" > /dev/cgroup/cpu/release_agent

Now I know, thank you all!

Will remove and see what happens...

On the contrary miffojon, the thanks go to you.

I commented out those 4 lines and, predictably, the unwanted mount went away.

I don't think I would have ever looked in rc.local for a script such as that!

[miffojon]

Well we're all pretty good at what we do
Remove this file: /usr/local/sbin/cgroup_clean
as well.

[Jesse654]

I've been wondering what this was in my /etc/rc.local:

mkdir -p /dev/cgroup/cpu
mount -t cgroup cgroup /dev/cgroup/cpu -o cpu
mkdir -m 0777 /dev/cgroup/cpu/user
echo "/usr/local/sbin/cgroup_clean" > /dev/cgroup/cpu/release_agent

Now I know, thank you all!

Will remove and see what happens...

This looks to be the 4 lines of code that a Red Hat programmer came up with that was equivalent to the 200 line kernel patch that was in the news so much last year (Nov). It's no wonder Anakinholland saw it on his Red Hat system late last year.

Here is a link to an article (one of many):
http://jasper-22.blogspot.com/2010/11/f ... ds-up.html

Do you really want to remove it? I remember reading a post from Linus about how his system worked so much better with it.

[miffojon]

Could be good, but since I don't have cgroup-bin or libcgroup1 installed I'll remove it until I know what the advantage is.
For anyone with a server it might make sense:
http://www.serverwatch.com/tutorials/article.php/3921001/Setting-Up-Linux-Cgroups.htm

[viking777]

This looks to be the 4 lines of code that a Red Hat programmer came up with that was equivalent to the 200 line kernel patch that was in the news so much last year (Nov). It's no wonder Anakinholland saw it on his Red Hat system late last year.

Here is a link to an article (one of many):
http://jasper-22.blogspot.com/2010/11/f ... ds-up.html

Do you really want to remove it? I remember reading a post from Linus about how his system worked so much better with it.

Now that is really good information Jesse654. Even more thanks to hand out .

Do I want to remove it? Well probably still yes.

I am glad that Linus was able to notice such a vast improvement in his system, but it wasn't in the least bit obvious to me. However I haven't actually removed it yet, only commented out the lines in the rc.local, so I am keeping my options open. I notice that Linus is quoted as saying:

the difference between the Red Hat engineer's userspace 4 line patch and the 200 line patch in the Linux kernel, is a question of automation.

And he is probably right, Lord knows he understands an awful lot more than I do! But for me that is not what matters, what matters is that if I have a 200 line kernel patch inserted into my kernel, I will never know anything about it if I live to be as old as Methuselah. But if I get sudden unexplained mount points appearing in my system I am going to notice it and I am going to think - hack, virus, rootkit, who knows what. And I don't like that, so give me the 200 line kernel patch every time please.

[Jesse654]

This link:
https://lkml.org/lkml/2010/11/20/91
will get you into the heart of the discussion from a year ago on the kernel mailing list. It talks of Mike Galbraith's patch which I'm assuming is the 200 loc. I recall that the Red Hat developer with the 4 loc userland patch said it was easier to track (the behavior of the change) via userland than in the kernel. Linus said that he would want it in the kernel so that it is there without any distro needing to add it. (But it can be configured via kernel option and turned off/on on-the-fly). Also, there seems to be a lot of discussion on the lkml over the last year re cgroups; a simple google search will show this.

I can only assume that at some point (past, present or future) this was/is/will be in the kernel.

Oh, I remember Linus saying that the purpose of this patch was to "even out processing" (my wording) when a system is under stress. IOW, when Linus is using mega-processing power compiling, he is able to search his email or scroll a window more smoothly when "automated per session task groups" (aka, "autogroups") is enabled. (Streaming real-time video might be a relevant example for a non-programmer.)

Mike posted some initial numbers comparing times with and without autogroups. (I had the link somewhere, but I think it's on my other computer...)

Don't know if any of this info is helpful, but that's pretty much all I know/remember about it.