'cset shield' is not able to work with /cpusets/cpuset.cpus on Suse 12.1

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use a 12-core (2 processors, 6 cores each) machine with Suse 12.1
2. cset shield
3. Error message: [Errno 2] No such file or directory: '/cpusets//cpus'

What is the expected output? What do you see instead?
Expected is that cset returns that shielding is not active (since cpusets were 
not manipulated before and cset itself cannot be used due to this error). 
Instead, the error message is displayed.

What version of the product are you using? On what operating system?
openSuse 12.1

cset --version
cset: Cpuset (cset) 1.5.6

uname -srvmpio
Linux 3.0.12-rt30-1.2-desktop #1 SMP PREEMPT RT Thu Dec 8 10:18:29 CET 2011 
i686 i686 i386 GNU/Linux

Please provide any additional information below.

Instead of lying at /cpusets/cpus (e.g. Suse 11.2), the file is now at 
/cpusets/cpuset.cpus (see below). The cset tool is not able to work with these 
new paths.
Does anyone know when and why this was changed? I didn't find any hints on the 
web.

ll /cpusets (after patching the cset.py, therefore system and tasks are new)
total 0
-rw-r--r-- 1 root root 0 Dec 14 15:57 cgroup.clone_children
--w--w--w- 1 root root 0 Dec 14 15:57 cgroup.event_control
-rw-r--r-- 1 root root 0 Dec 14 15:57 cgroup.procs
-rw-r--r-- 1 root root 0 Dec 14 15:57 cpuset.cpu_exclusive
-rw-r--r-- 1 root root 0 Dec 14 15:57 cpuset.cpus
-rw-r--r-- 1 root root 0 Dec 14 15:57 cpuset.mem_exclusive
-rw-r--r-- 1 root root 0 Dec 14 15:57 cpuset.mem_hardwall
-rw-r--r-- 1 root root 0 Dec 14 15:57 cpuset.memory_migrate
-r--r--r-- 1 root root 0 Dec 14 15:57 cpuset.memory_pressure
-rw-r--r-- 1 root root 0 Dec 14 15:57 cpuset.memory_pressure_enabled
-rw-r--r-- 1 root root 0 Dec 14 15:57 cpuset.memory_spread_page
-rw-r--r-- 1 root root 0 Dec 14 15:57 cpuset.memory_spread_slab
-rw-r--r-- 1 root root 0 Dec 14 15:57 cpuset.mems
-rw-r--r-- 1 root root 0 Dec 14 15:57 cpuset.sched_load_balance
-rw-r--r-- 1 root root 0 Dec 14 15:57 cpuset.sched_relax_domain_level
-rw-r--r-- 1 root root 0 Dec 14 15:57 notify_on_release
-rw-r--r-- 1 root root 0 Dec 14 15:57 release_agent
drwxr-xr-x 2 root root 0 Dec 22 13:31 system
-rw-r--r-- 1 root root 0 Dec 22 14:04 tasks

After I've patched the cset.py file, everything worked fine. It would be nice 
if the cset tool would be extended by a detection logic, which file structure 
is used.

I've attached
- diff of the patched cset.py file
- output of  "cat /proc/cpuinfo"
- debug failure log of "cset shield"

Original issue reported on code.google.com by niheuerm...@googlemail.com on 22 Dec 2011 at 1:48

Attachments:

• cpuinfo.txt
• cset_failure.log
• diff_for_cset.py

[GoogleCodeExporter]

Thanks for the detailed report.  These variable names changed with the 
introduction of cgroups into the 3.x kernels.  Will address soon.

Original comment by tsariou...@gmail.com on 15 Feb 2012 at 5:55

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by tsariou...@gmail.com on 15 Feb 2012 at 5:59

[GoogleCodeExporter]

Hi,

Any news on this issue ?

Best regards

Original comment by Benj.P...@gmail.com on 26 Jul 2012 at 12:08

[GoogleCodeExporter]

Hi: sorry no news yet; I"ve not had the time to invest.  I suggest using the 
cgroup fs directly with normal linux fs commands.  There are a lot of new knobs 
with control groups and new functionality.  All of that is available in the 
"manual" way with normal mkdir/rmdir/mv/echo/cat commands.

Original comment by tsariou...@gmail.com on 26 Jul 2012 at 5:52

[GoogleCodeExporter]

Hi,

There is a patch from Ubuntu support, I don't know if you already get it, so I 
attach it.

best regards

Original comment by Benj.P...@gmail.com on 7 Aug 2012 at 4:09

Attachments:

• cset.py

[GoogleCodeExporter]

It turns out that at least for 3.2 you have both versions for cpus 
('cpuset.cpus' and just 'cpus'). Which of the two you get is at least partially 
decided by how the FS is mounted. 'mount -t cgroup' seems to give 'cpuset.cpus' 
and 'mount -t cpuset' just plain 'cpus'.

But apart from how cpuset is mounted it also depends on the interaction, e.g. 
creating a group through one of the two seems to define the naming for the 
other mount variant.

Original comment by erase...@gmail.com on 7 Nov 2012 at 12:28

[GoogleCodeExporter]

This issue still exists with OpenSUSE 12.2 and 12.3 (64bit versions with 4 
respectivley 2 cores) and cset: Cpuset (cset) 1.5.6

The Patch from Ubuntu posted by Benj.P works well

Original comment by nichtess...@gmail.com on 3 May 2013 at 1:53

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I am sorry about asking this: I am new to cpuset, and I cannot get the patch to 
work. I am running opensuse-12.3. I get the error "cset: **> [Errno 2] No such 
file or directory: '/cpusets//cpus'". 

can someone please tell me how do I get the patch to work?

Original comment by deven...@gmail.com on 11 Dec 2013 at 10:08

[GoogleCodeExporter]

I'am also stuck. Im getting this kind of error and could not resolve for days.
cset: /cpusets/libvirt/lxc is not a cpuset directory
cset: **> /cpusets/libvirt/lxc is not a cpuset directory

Original comment by cmunsa...@liquidcapital.com on 31 Mar 2015 at 12:49

[GoogleCodeExporter]

The modified file linked to by Benj.P above is not quite complete. Here's one 
that works with current upstream kernels.

Original comment by j...@tsp.io on 7 Jul 2015 at 10:08

Attachments:

• add-cpuset-prefix.patch