Created attachment 69888 [details]
As I read the cgroups vs cgroups article, one need only enable "CONFIG_CGROUPS=y" to use systemd correctly. My system running a bfs patched kernel that does in deed have that set:
$ zgrep CONFIG_CGROUPS=y /proc/config.gz
I do see a peculiar line in the journalctl and am wondering if it is a bug or if I need to setup something else that I missed in the article. Systemd seems to function on my system just fine. Thank you in advance for any insight into this message.
Error message: "Failed to create cgroup cpu:/: No such file or directory"
I attached /proc/config.gz from the machine which is an older i686 but I get this same message on my workstation which is an x86_64/Corei7.
P.S. I posted this to the mailing list but noticed afterwards that only the bugzilla-daemon seems to post there so I opened this task.
Where exactly do you see this error messages and how often? Usually it should be safe to ignore it, but we probably should supress it altogether if the "cpu" controller is not available.
I can also confirm this problem report.
The "systemd" logged error is:
"systemd: Failed to create cgroup cpu:/: No such file or directory"
Despite the documentation at http://0pointer.de/blog/projects/cgroups-vs-cgroups.html stating that "(B) you may disable all of the latter options while enabling "CONFIG_CGROUPS=y", if you want to run systemd on your system.", it now appear to be true that this is not enough, or has been changed in the later kernel release and/or systemd?
The above logged 'error' occurs on every boot instance [with the kernel options = "CONFIG_CGROUPS=y" + "CONFIG_CGROUP_CPUACCT=y".
The *tested solution* [with Linux 3.8.8+] is to compile the kernel with the additional "CONFIG_CGROUP_SCHED=y"! [no official doc's on that yet?].
Another reportor of this [same] issue was seen at "http://lists.freedesktop.org/archives/systemd-devel/2012-June/005500.html" - 10 months ago.
Some updated documentation would be good. [via systemd and the kernel relationship]...
I think this is caused by the following lines in rtkit-daemon.service:
# Work around the fact that the Linux currently doesn't assign any RT
# budget to CPU control groups that have none configured explicitly
The message then shows up when rtkit-daemon starts.
(In reply to comment #4)
> I think this is caused by the following lines in rtkit-daemon.service:
> # Work around the fact that the Linux currently doesn't assign any RT
> # budget to CPU control groups that have none configured explicitly
> The message then shows up when rtkit-daemon starts.
I have that same setting in that same file, and dmesg reports that same error message. However, `systemctl status rtkit-daemon.service` does not catch the error.
Is it safe to comment out that line?
In case it matters: I have a 6 core (12 HT) Intel Westmere CPU, which I believe has its own built-in CPU scheduling mechanism. I'm using Linux 3.9.7-1-ck kernel, which is from the Arch Linux repo-ck repository of Intel-optimised, pre-compiled kernels. I use the Nehalem-optimised one, which is compiled with BFS support...
Reason, there is no ControlGroup, it dissapeared in systemd 205 or later.
on Mar 24, 2017 at 11:57:48.
(provided by the Example extension).