Description of problem: systemd cannot safely and persistently change the size of the /tmp tmpfs. The size can be changed in /usr/lib/systemd/system/tmp.mount, but this file is not marked as a config file and is overwritten by a systemd update. Version-Release number of selected component (if applicable): systemd-195-15.fc18.x86_64 How reproducible: 100% Steps to Reproduce: 1. Add "size=$Ng" to Options= line in /usr/lib/systemd/system/tmp.mount 2. reboot 3. update systemd 4. reboot Actual results: tmpfs size is picked up on first reboot but resets to default on second reboot Expected results: there should be a way to persist this configuration beyond systemd update via a config file correctly marked as such in the rpm.
This is expected behaviour users should copy the /usr/lib/systemd/system/tmp.mount to /etc/systemd/system/tmp.mount and edit it there. Can you test if that works or works not for you and make note of that here on the bug
I was pointed towards /etc/systemd/system/tmp.mount as an override location, but that's not listed in the man pages that I can see --- systemd(1) lists only /usr/local/lib/systemd/system and /usr/lib/systemd/system. We should make sure the override location is at least documented correctly, and preferably made a bit more obvious, potentially via # comments in the /usr/lib/* files.
You should be able to add the custom entry to fstab, and all should work as expected without any further copying or configuration.
> You should be able to add the custom entry to fstab, and all should work as > expected Then shouldn't the configuration already be in fstab? That's the most obvious place for a sysadmin to go looking for options for default mounted filesystems. The rest of the content of systemd/system/tmp.mount is fine, but it seems far preferable to have the fs options themselves (currently the mode=1777,strictatime options) in fstab.
We generally try to keep virtual "API" file systems out of fstab these days, so that that file only contains actual real file systems managed by the user/admin. That's why we keep /dev, /sys, /proc, /run, /dev/shm, /sys/fs/cgroup, /tmp, ... out of it by default. However, if people do list them in fstab we will apply their settings. /tmp is more or less just an API file system (i.e. it's used mostly unknown to the user and is not a place to persistently store stuff), the same way as /dev/shm is (in fact, it's very identical to that, as that too is a world-writable tmpfs), and hence we follow the same logic there. Normally it should not be necessary for admins to alter the mount options of these fs. Changing the options is hence the exception, not the rule. Hence we allow a nice way to change it, but will not litter the file with options irrelevant for most cases. I will now retitle the bug to request that we write some better documentation for people to change the mount options of all these file systems, not just /tmp.
*** Bug 858265 has been marked as a duplicate of this bug. ***
I have now written http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems and linked it up in the FAQ as well as a number of systemd man pages and unit files. That should settle the issue.
systemd-201-2.fc18.1 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-201-2.fc18.1
Package systemd-201-2.fc18.2: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.2' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.2 then log in and leave karma (feedback).
Package systemd-201-2.fc18.4: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.4' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.3 then log in and leave karma (feedback).
Package systemd-201-2.fc18.5: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.5 then log in and leave karma (feedback).
systemd-201-2.fc18.6 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
Package systemd-201-2.fc18.6: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6 then log in and leave karma (feedback).
systemd-201-2.fc18.6 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.