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[1]: [/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 [Unit] Description=PHP-FPM server for binding cem [Service] User=site_exp_mon Group=site_exp_mon Restart=on-failure 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 KillMode=process TimeoutSec=15s # 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 CPUShares=250 #MemoryLimit=512M #MemorySoftLimit=M BlockIOWeight=100 [Install] WantedBy=multi-user.target And here's the version of systemd we're running on that box: [straussd@endpointd64dcb37 ~]$ yum info systemd sensu 20/20 Installed Packages 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[1]: [/usr/lib/systemd/system/boinc- client.service:8] Unknown or unsupported cgroup attribute CPUShares, ignoring: 2 However, I also came across this: http://cgit.freedesktop.org/systemd/systemd/commit/?id=ccd90a976dbaf2acd1b62eb46f26bc35ae090467 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.