'cset shield' is not able to work with /cpusets/cpuset.cpus on Suse 12.1
Closed this issue · 12 comments
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:
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
Original comment by tsariou...@gmail.com
on 15 Feb 2012 at 5:59
Hi,
Any news on this issue ?
Best regards
Original comment by Benj.P...@gmail.com
on 26 Jul 2012 at 12:08
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
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:
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
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
[deleted comment]
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
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
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: