Red Hat Bugzilla – Bug 988563
Regression: CPUShares= directive not recognized
Last modified: 2013-12-22 23:21:51 EST
In a service, the CPUShares= directive should control the corresponding cgroups attribute, as documented in the systemd.exec manpage. Instead, it fails to recognize the directive and does nothing.
It's easy to reproduce: just add CPUShares=1000 to a service (in the [Service] section), tail the journal, systemctl daemon-reload, and restart the service. It should complain.
I noted that it's a regression because the directive certainly used to work when we added to our Chef recipes, and there's not reason it should have stopped working.
Which version of systemd? This really should just work.
Hmm, not seeing this on my desktop if I install nginx and then just add CPUShares, but I do see it on our servers.
Here's the log entry, which we get for all units like this:
Jul 23 22:43:50 endpointd64dcb37 systemd: [/etc/systemd/system/php_fpm_site_exp_mon.service:27] Unknown or unsupported cgroup attribute CPUShares, ignoring: 250
Here's the full unit file:
[straussd@endpointd64dcb37 ~]$ sudo cat /etc/systemd/system/php_fpm_site_exp_mon.service
# Dropped off by Chef
Description=PHP-FPM server for binding cem
ExecStart=/opt/php-5.3/php-fpm --fpm-config=/opt/site_experience_monitor/php-fpm.conf --php-ini=/opt/site_experience_monitor/php53.ini
ExecReload=/bin/kill -USR2 $MAINPID
# Filesystem restrictions
# There are read-dependencies on /usr, /bin, /dev, /lib, /lib64, /proc, /srv, /dev, /proc
# There are read/write dependencies on /tmp /srv
# We'd like to remove dependencies and lock-down /dev /proc /tmp /srv
# /etc is used for /etc/php.d
ReadWriteDirectories=/opt/site_experience_monitor/run /opt/site_experience_monitor/logs /opt/site_experience_monitor/files /tmp
ReadOnlyDirectories=/opt/site_experience_monitor/code /usr /bin /dev /lib /lib64 /proc /dev /etc
# This last one didn't want to work so we're skipping it for now
#InaccessibleDirectories=/boot /home /media /mnt /opt /root /run /sbin /selinux /sys /var /etc/pantheon
# Basic Cgroups Config
# Per: http://0pointer.de/public/systemd-man/systemd.exec.html
And here's the version of systemd we're running on that box:
[straussd@endpointd64dcb37 ~]$ yum info systemd
Name : systemd
Arch : x86_64
Version : 204
Release : 9.fc19
Size : 10 M
Repo : installed
From repo : updates-testing
Not sure why it says "updates-testing". It's the current stable repo release: https://admin.fedoraproject.org/updates/FEDORA-2013-11662/systemd-204-9.fc19
I came across the same error message when running BOINC:
Aug 29 16:49:30 jhorne systemd: [/usr/lib/systemd/system/boinc-
client.service:8] Unknown or unsupported cgroup attribute CPUShares, ignoring: 2
However, I also came across this:
which seems to indicate that it has been fixed upstream. If this was a regression then there is no indication of why/how it happened.
systemd RPM is currently systemd-204-9.fc19.x86_64
Yes, that commit almost certainly fixes it. That ought to be backported to F18+.
One of the previous updates for F19 had this patch. Reassigning to F18.
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '18'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 18's end of life.
Thank you for reporting this issue and we are sorry that we may not be
able to fix it before Fedora 18 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior to Fedora 18's end of life.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
This was fixed by last (or maybe previous) update.