Summary: | sys-apps/openrc - /lib64/rc/sh/rc-cgroup.sh: line 67: echo: write error: No space left on device | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Marcin Mirosław <bug> |
Component: | OpenRC | Assignee: | OpenRC Team <openrc> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | aoaaxy+gentoobugzilla, zazdxscf+bugs.gentoo.org |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Marcin Mirosław
2014-11-21 11:32:56 UTC
Hello, Mirosław. Thanks for your report! At first I want to say that there is no bug involved here, but your question shows that documentation should be improved and maybe we will have to introduce more checks. Your configuration file (/etc/conf.d/cpuburn) should have following options: rc_cgroup_cpuset=" cpuset.mems 0 cpuset.cpus 1 " Then everything will work, i.e. cpuburn will use eating first cpu only. The correct syntax is: rc_cgroup_<name-of-the-hierarchy>=" <name-of-the-file-1> <value> <name-of-the-file-2> <value> " where name of the file generally is <name-of-the-hierarchy>.<option-name>. So I see 2 issues here: 1. openrc do not perform additional checks and throws out meaningless 'No space left on device'. The reason is simple as you have used cpuset hier process should me moved in his place in the hierarchy, but it was not configured before (i.e. cpuset.mems was not set to zero). I'm not sure that there is an easy way forward at just wrap a error message with some information that will show that there is a problem with cgroup configuration 2. documentation problem, here is quote from self documenting /etc/rc.conf file # The format is to specify the names of the settings followed by their # values. Each variable can hold multiple settings. # For example, you would use this to set the cpu.shares setting in the # cpu controller to 512 for your service. # rc_cgroup_cpu=" # cpu.shares 512 # " do you see a ways how it can be written better? maybe you prefer additional source on the wiki? Thank you Александр for detailed explanation. Now I can use cgroup without problem, at least pinning to cpu works:) If you put to rc.conf what you wrote to me: rc_cgroup_<name-of-the-hierarchy>=" <name-of-the-file-1> <value> <name-of-the-file-2> <value> " example: rc_cgroup_cpuset=" cpuset.mems 0 cpuset.cpus 1 " I think everything will be much more clear for people which wnat to use this feature. Als it could be nice to check if `echo pid > tasks` finished without error, if not it would be nice to get message like: "You didn't configure all cgroup parameters correctly, please check it". Because using "cgroup.cpus" needs "cgroup.mems" configured earlier it would be great to give advice to user: (pseudocode) if ! `echo pid > tasks` || "user used cpuset.cpus" then echo "you set cgroup.cpus, did you set cpugroup.mems also?" fi (In reply to Marcin Mirosław from comment #2) > Thank you Александр for detailed explanation. Now I can use cgroup without > problem, at least pinning to cpu works:) If you put to rc.conf what you > wrote to me: > > rc_cgroup_<name-of-the-hierarchy>=" > <name-of-the-file-1> <value> > <name-of-the-file-2> <value> > " > > example: > rc_cgroup_cpuset=" > cpuset.mems 0 > cpuset.cpus 1 > " I think it's doable I'll prepare a pull request soon. > I think everything will be much more clear for people which wnat to use this > feature. > Als it could be nice to check if `echo pid > tasks` finished without error, > if not it would be nice to get message like: > "You didn't configure all cgroup parameters correctly, please check it". Reasonable, I'll consult about actual phrase. > Because using "cgroup.cpus" needs "cgroup.mems" configured earlier it would > be great to give advice to user: (pseudocode) > if ! `echo pid > tasks` || "user used cpuset.cpus" then > echo "you set cgroup.cpus, did you set cpugroup.mems also?" > fi I'm personally not happy with adding checks to the rc scripts as checking everything will blow up a script, and it's not used by the most people, also currently there are many constraints that is not easy to track. So I think we will end with generic error message that is less cryptic than it was before. I have been unable to reproduce this issue with any services on my system. Also, there was a cgroups fix applied to OpenRC-0.18.3 which took care of several cgroups-related issues. Can you test with OpenRC-0.18.3 and re-open this bug if this still occurs? Disregard previous, I'll look at this again. |