Description of problem: When configuring limits (memory, CPU, block I/O, etc.) using systemd's built-in options, the options often fail to apply. Version-Release number of selected component (if applicable): Verified as a problem on F16 builds 36-3 and 37-2. How reproducible: Reliably. Steps to Reproduce: 1. Configure a service unit with cgroups limits. 2. systemctl --system daemon-reload 3. systemctl restart NAME.service 4. Check the cgroup limits for the server. They should currently be correct. 5. systemctl restart NAME.service 6. systemctl restart NAME.service # A third restart usually isn't necessary to reproduce the problem, but I did see *once* where it was. 7. Check the cgroup limits for the server. They should currently be correct. It usually only takes one more restart to lose the ability to write the limits. Actual results: cgroups limits get set properly only when a service is (re)started immediately after a systemd daemon reload. Expected results: cgroups limits that survive service restarts consistently. Additional info: I'm seeing this problem with the F16 packages of systemd 36-3 and 37-2 on F15. I'm currently installing the F16 pre-release to see if I can reproduce it on a clean F16 system. I've attached a console log showing (1) systemd trying but failing to write to the cgroups for the service (2) various interactions with the service and reloading systemd (3) the service unit file.
Created attachment 530584 [details] Console log
(In reply to comment #0) > Steps to Reproduce: > 1. Configure a service unit with cgroups limits. > 2. systemctl --system daemon-reload > 3. systemctl restart NAME.service > 4. Check the cgroup limits for the server. They should currently be correct. > 5. systemctl restart NAME.service > 6. systemctl restart NAME.service # A third restart usually isn't necessary to > reproduce the problem, but I did see *once* where it was. > 7. Check the cgroup limits for the server. They should currently be correct. > > It usually only takes one more restart to lose the ability to write the limits. Whoops, that's wrong. Here's what I meant to write: Steps to Reproduce: 1. Configure a service unit with cgroups limits. 2. systemctl --system daemon-reload 3. systemctl restart NAME.service 4. Check the cgroup limits for the server. They should currently be correct. 5. systemctl restart NAME.service 6. systemctl restart NAME.service # A third restart usually isn't necessary to reproduce the problem, but I did see *once* where it was. 7. Check the cgroup limits for the server. They should currently be *incorrect*. It usually only takes *two restarts* after the systemd reload to lose the ability to write the limits.
Just verified on a fresh installation of F16. See the attached screenshots with the relevant info using a *very* simple service (a simple unit running a Python script that simply sleeps 600 seconds).
Created attachment 530587 [details] F16 verification
Created attachment 530588 [details] tail of messages on F16
Fixed now upstream in git.
I can vouch for this fix working.
systemd-37-6.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/systemd-37-6.fc16
Package systemd-37-6.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-6.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-6.fc16 then log in and leave karma (feedback).
Package systemd-37-7.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-7.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-7.fc16 then log in and leave karma (feedback).
Package systemd-37-8.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-8.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-8.fc16 then log in and leave karma (feedback).
Package systemd-37-10.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-10.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-10.fc16 then log in and leave karma (feedback).
Package systemd-37-11.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-11.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-11.fc16 then log in and leave karma (feedback).
systemd-37-11.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.