Hello,
Since installing FC20, I've been struggling to deal with the fact that something is eating files in /tmp before I'm done with them. (I'm not talking about reboots.) If I create a file in /tmp, within N minutes, it is deleted. This is problematic since I have quite a few tools/tasks that require creating transient files in /tmp that need to exist for the duration of the process that creates them. I removed tmpwatch, assuming that was the problem but that did nothing.
After some research I've found tmpfiles.d, which can't be removed because it is wrapped in the systemd package. I attempted to disable cleaning of /tmp and /var/tmp by making the following change to /usr/lib/tmpfiles.d/tmp.conf but no dice:
----------------------- # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version.
# See tmpfiles.d(5) for details
# Clear tmp directories separately, to make them easier to override #d /tmp 1777 root root 10d #d /var/tmp 1777 root root 30d
# Exclude namespace mountpoints created with PrivateTmp=yes x /tmp x /var/tmp X /tmp X /var/tmp x /tmp/* x /var/tmp/* X /tmp/* X /var/tmp/* #x /tmp/systemd-*.service-* #x /var/tmp/systemd-*.service-* #X /tmp/systemd-*.service-*/tmp #X /var/tmp/systemd-*.service-*/tmp #x /tmp/systemd-*.socket-* #x /var/tmp/systemd-*.socket-* #X /tmp/systemd-*.socket-*/tmp #X /var/tmp/systemd-*.socket-*/tmp #x /tmp/systemd-*.mount-* #x /var/tmp/systemd-*.mount-* #X /tmp/systemd-*.mount-*/tmp #X /var/tmp/systemd-*.mount-*/tmp #x /tmp/systemd-*.swap-* #x /var/tmp/systemd-*.swap-* #X /tmp/systemd-*.swap-*/tmp #X /var/tmp/systemd-*.swap-*/tmp ## keep those for compatibility during upgrades #x /tmp/systemd-private-* #x /var/tmp/systemd-private-* #X /tmp/systemd-private-*/tmp #X /var/tmp/systemd-private-*/tmp -----------------------
Can someone point me to the correct way to fix this problem?
On 17.04.2014 23:19, Tucker wrote:
Hello,
Since installing FC20, I've been struggling to deal with the fact that something is eating files in /tmp before I'm done with them. (I'm not talking about reboots.) If I create a file in /tmp, within N minutes, it is deleted. This is problematic since I have quite a few tools/tasks that require creating transient files in /tmp that need to exist for the duration of the process that creates them. I removed tmpwatch, assuming that was the problem but that did nothing.
After some research I've found tmpfiles.d, which can't be removed because it is wrapped in the systemd package. I attempted to disable cleaning of /tmp and /var/tmp by making the following change to /usr/lib/tmpfiles.d/tmp.conf but no dice:
# This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version.
# See tmpfiles.d(5) for details
# Clear tmp directories separately, to make them easier to override #d /tmp 1777 root root 10d #d /var/tmp 1777 root root 30d
# Exclude namespace mountpoints created with PrivateTmp=yes x /tmp x /var/tmp X /tmp X /var/tmp x /tmp/* x /var/tmp/* X /tmp/* X /var/tmp/* #x /tmp/systemd-*.service-* #x /var/tmp/systemd-*.service-* #X /tmp/systemd-*.service-*/tmp #X /var/tmp/systemd-*.service-*/tmp #x /tmp/systemd-*.socket-* #x /var/tmp/systemd-*.socket-* #X /tmp/systemd-*.socket-*/tmp #X /var/tmp/systemd-*.socket-*/tmp #x /tmp/systemd-*.mount-* #x /var/tmp/systemd-*.mount-* #X /tmp/systemd-*.mount-*/tmp #X /var/tmp/systemd-*.mount-*/tmp #x /tmp/systemd-*.swap-* #x /var/tmp/systemd-*.swap-* #X /tmp/systemd-*.swap-*/tmp #X /var/tmp/systemd-*.swap-*/tmp ## keep those for compatibility during upgrades #x /tmp/systemd-private-* #x /var/tmp/systemd-private-* #X /tmp/systemd-private-*/tmp
#X /var/tmp/systemd-private-*/tmp
Can someone point me to the correct way to fix this problem?
man 5 tmpfiles.d ... Files in /etc/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d and /run/tmpfiles.d. Files in /run/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d. Packages should install their configuration files in /usr/lib/tmpfiles.d. Files in /etc/tmpfiles.d are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same path, the entry in the file with the lexicographically earliest name will be applied, all all other conflicting entries logged as errors.
If the administrator wants to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in /etc/tmpfiles.d/ bearing the same filename.
# ln -s /dev/null /etc/tmpfiles.d/tmp.conf # file /etc/tmpfiles.d/tmp.conf /etc/tmpfiles.d/tmp.conf: symbolic link to `/dev/null'
Working?
poma
Presumably, removing all the files in those directories would do the same but it appears that it's still purging /tmp. Does systemd-tmpfiles require a reload/restart before it picks up changes? If so, that conveniently requires a reboot since it ignores manual anything. I'd love to be able to completely kill it but my familiarity with systemd is very limited. Anyone care to venture a guess about what would happen if I removed the executable bit from the binary?
For now I've symlinked all of the files in the tmpfiles.d directories to /dev/null. Let's see what happens...
On Thu, Apr 17, 2014 at 4:00 PM, poma pomidorabelisima@gmail.com wrote:
On 17.04.2014 23:19, Tucker wrote:
Hello,
Since installing FC20, I've been struggling to deal with the fact that something is eating files in /tmp before I'm done with them. (I'm not talking about reboots.) If I create a file in /tmp, within N minutes, it is deleted. This is problematic since I have quite a few tools/tasks
that
require creating transient files in /tmp that need to exist for the duration of the process that creates them. I removed tmpwatch, assuming that was the problem but that did nothing.
After some research I've found tmpfiles.d, which can't be removed because it is wrapped in the systemd package. I attempted to disable cleaning of /tmp and /var/tmp by making the following change to /usr/lib/tmpfiles.d/tmp.conf but no dice:
# This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published
by
# the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version.
# See tmpfiles.d(5) for details
# Clear tmp directories separately, to make them easier to override #d /tmp 1777 root root 10d #d /var/tmp 1777 root root 30d
# Exclude namespace mountpoints created with PrivateTmp=yes x /tmp x /var/tmp X /tmp X /var/tmp x /tmp/* x /var/tmp/* X /tmp/* X /var/tmp/* #x /tmp/systemd-*.service-* #x /var/tmp/systemd-*.service-* #X /tmp/systemd-*.service-*/tmp #X /var/tmp/systemd-*.service-*/tmp #x /tmp/systemd-*.socket-* #x /var/tmp/systemd-*.socket-* #X /tmp/systemd-*.socket-*/tmp #X /var/tmp/systemd-*.socket-*/tmp #x /tmp/systemd-*.mount-* #x /var/tmp/systemd-*.mount-* #X /tmp/systemd-*.mount-*/tmp #X /var/tmp/systemd-*.mount-*/tmp #x /tmp/systemd-*.swap-* #x /var/tmp/systemd-*.swap-* #X /tmp/systemd-*.swap-*/tmp #X /var/tmp/systemd-*.swap-*/tmp ## keep those for compatibility during upgrades #x /tmp/systemd-private-* #x /var/tmp/systemd-private-* #X /tmp/systemd-private-*/tmp
#X /var/tmp/systemd-private-*/tmp
Can someone point me to the correct way to fix this problem?
man 5 tmpfiles.d ... Files in /etc/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d and /run/tmpfiles.d. Files in /run/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d. Packages should install their configuration files in /usr/lib/tmpfiles.d. Files in /etc/tmpfiles.d are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same path, the entry in the file with the lexicographically earliest name will be applied, all all other conflicting entries logged as errors.
If the administrator wants to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in /etc/tmpfiles.d/ bearing the same filename.
# ln -s /dev/null /etc/tmpfiles.d/tmp.conf # file /etc/tmpfiles.d/tmp.conf /etc/tmpfiles.d/tmp.conf: symbolic link to `/dev/null'
Working?
poma
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 04/17/2014 04:24 PM, Tucker wrote:
Does systemd-tmpfiles require a reload/restart before it picks up changes? If so, that conveniently requires a reboot since it ignores manual anything.
The service you probably want is systemd-tmpfiles-clean.service.
systemctl restart systemd-tmpfiles-clean.service
run as root should do the trick.
That's helpful, thanks. There appear to be a number of services that depend on the tmpfiles.d conf files. I don't want to break things like kmod, I just want this thing that's doing Bad Things to my transient files in /*/tmp/* directories to stop.
On Thu, Apr 17, 2014 at 4:31 PM, Joe Zeff joe@zeff.us wrote:
On 04/17/2014 04:24 PM, Tucker wrote:
Does systemd-tmpfiles require a reload/restart before it picks up changes? If so, that conveniently requires a reboot since it ignores manual anything.
The service you probably want is systemd-tmpfiles-clean.service.
systemctl restart systemd-tmpfiles-clean.service
run as root should do the trick.
Hi
On Thu, Apr 17, 2014 at 7:43 PM, Tucker wrote:
That's helpful, thanks. There appear to be a number of services that depend on the tmpfiles.d conf files. I don't want to break things like kmod, I just want this thing that's doing Bad Things to my transient files in /*/tmp/* directories to stop.
Maybe the right answer is to file a bug report rather than workaround it?
Rahul
I don't see a bug here. I see a BOFH that doesn't like the new way of things (Bring me my XFCE, dammit! And get off my lawn!) and using a work around is how I expect my life to work. If I didn't want/expect to kick things around until it worked the way I wanted, I'd be using an Apple.
On Thu, Apr 17, 2014 at 4:56 PM, Rahul Sundaram metherid@gmail.com wrote:
Hi
On Thu, Apr 17, 2014 at 7:43 PM, Tucker wrote:
That's helpful, thanks. There appear to be a number of services that depend on the tmpfiles.d conf files. I don't want to break things like kmod, I just want this thing that's doing Bad Things to my transient files in /*/tmp/* directories to stop.
Maybe the right answer is to file a bug report rather than workaround it?
Rahul
On 04/18/2014 12:56 AM, Rahul Sundaram wrote:
On Thu, Apr 17, 2014 at 7:43 PM, Tucker wrote:
That's helpful, thanks. There appear to be a number of services that depend on the tmpfiles.d conf files. I don't want to break things like kmod, I just want this thing that's doing Bad Things to my transient files in /*/tmp/* directories to stop.
Maybe the right answer is to file a bug report rather than workaround it?
Surely, yes. This behaviour will break all manner of things in hard-to- debug ways.
Andrew.
On Apr 20, 2014, at 2:00 AM, Andrew Haley aph@redhat.com wrote:
On 04/18/2014 12:56 AM, Rahul Sundaram wrote:
On Thu, Apr 17, 2014 at 7:43 PM, Tucker wrote:
That's helpful, thanks. There appear to be a number of services that depend on the tmpfiles.d conf files. I don't want to break things like kmod, I just want this thing that's doing Bad Things to my transient files in /*/tmp/* directories to stop.
Maybe the right answer is to file a bug report rather than workaround it?
Surely, yes. This behaviour will break all manner of things in hard-to- debug ways.
No where in the original feature page does it say periodic cleaning of /tmp happens. In fact the opposite is indicated.
https://fedoraproject.org/wiki/Features/tmp-on-tmpfs
The cited blog indicates periodic clean up based on aging, and cites the FHS as saying files in /tmp aren't expected to be needed persistently between two runs of the application.
http://0pointer.de/blog/projects/tmp.html
I don't know when the aged based cleaning started, but it isn't expressly stated in the original feature and I'm not finding a followup feature that indicates this change. On the other hand, it sounds like most of the time applications shouldn't use (or depend on) /tmp anyway since they can't depend on any sort of persistence.
Chris Murphy
On Sun, Apr 20, 2014 at 09:11:58PM -0600, Chris Murphy wrote:
I don't know when the aged based cleaning started, but it isn't expressly stated in the original feature and I'm not finding a followup feature that indicates this change. On the other hand, it sounds like most of the time applications shouldn't use (or depend on) /tmp anyway since they can't depend on any sort of persistence.
We've been running tmpwatch on /tmp since... I don't even know when. Years.
On 04/21/2014 04:36 PM, Matthew Miller wrote:
On Sun, Apr 20, 2014 at 09:11:58PM -0600, Chris Murphy wrote:
I don't know when the aged based cleaning started, but it isn't expressly stated in the original feature and I'm not finding a followup feature that indicates this change. On the other hand, it sounds like most of the time applications shouldn't use (or depend on) /tmp anyway since they can't depend on any sort of persistence.
We've been running tmpwatch on /tmp since... I don't even know when. Years.
tmpwatch clears files every few minutes? Really? And this has not broken scripts? My tmp.conf says 10 days, but the OP said every few *minutes*.
Andrew.
On Thu, Apr 24, 2014 at 01:43:21PM +0100, Andrew Haley wrote:
On Sun, Apr 20, 2014 at 09:11:58PM -0600, Chris Murphy wrote:
I don't know when the aged based cleaning started, but it isn't expressly stated in the original feature and I'm not finding a followup feature that indicates this change. On the other hand, it sounds like most of the time applications shouldn't use (or depend on) /tmp anyway since they can't depend on any sort of persistence.
We've been running tmpwatch on /tmp since... I don't even know when. Years.
tmpwatch clears files every few minutes? Really? And this has not broken scripts? My tmp.conf says 10 days, but the OP said every few *minutes*.
I'm replying to "I don't know when the aged based cleaning started", as clearly quoted above.
For what it's worth, this is still FUBAR. I definitely see a bug here. I recently moved from Xubuntu -> Fedora XFCE -> "Plain" Fedora and this is when this all started happening. Both the Xfce respin and the "plain" setup were FC20. I've attempted to disable anything that might be eating things from /tmp and change all the configs I can find. The max lifetime of a file in /tmp if 60m. After teh 60m mark, it's gone. To be honest, the length of time that tmpwatch has been doing Bad Things (yes, I think force cleaning /tmp is Bad) is of little concern to me. The fact that there appears to be no way to make it stop, is a bug. When did this become tangled in the pile of spaghetti that is systemd?
On Thu, Apr 24, 2014 at 6:19 AM, Matthew Miller mattdm@fedoraproject.orgwrote:
On Thu, Apr 24, 2014 at 01:43:21PM +0100, Andrew Haley wrote:
On Sun, Apr 20, 2014 at 09:11:58PM -0600, Chris Murphy wrote:
I don't know when the aged based cleaning started, but it isn't
expressly
stated in the original feature and I'm not finding a followup feature
that
indicates this change. On the other hand, it sounds like most of the
time
applications shouldn't use (or depend on) /tmp anyway since they can't depend on any sort of persistence.
We've been running tmpwatch on /tmp since... I don't even know when.
Years.
tmpwatch clears files every few minutes? Really? And this has not
broken
scripts? My tmp.conf says 10 days, but the OP said every few *minutes*.
I'm replying to "I don't know when the aged based cleaning started", as clearly quoted above.
-- Matthew Miller -- Fedora Project -- mattdm@fedoraproject.org "Tepid change for the somewhat better!" -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Hi
On Thu, Apr 24, 2014 at 3:49 PM, Tucker wrote:
For what it's worth, this is still FUBAR. I definitely see a bug here.
... which is what I suggested earlier. I don't think anyone else is seeing this to help you workaround it. Please report this against systemd and developers involved can verify if there is a bug in it or elsewhere.
Rahul
Agreed. When you initially suggested it, I figured it was a problem with me and something I could fix if I understood what was going on. Now I think it's a problem with systemd/init/soup that a reasonably intelligent person can't be expected to deal with.
On Thu, Apr 24, 2014 at 12:58 PM, Rahul Sundaram metherid@gmail.com wrote:
Hi
On Thu, Apr 24, 2014 at 3:49 PM, Tucker wrote:
For what it's worth, this is still FUBAR. I definitely see a bug here.
... which is what I suggested earlier. I don't think anyone else is seeing this to help you workaround it. Please report this against systemd and developers involved can verify if there is a bug in it or elsewhere.
Rahul
On 04/25/14 04:08, Tucker wrote:
Agreed. When you initially suggested it, I figured it was a problem with me and something I could fix if I understood what was going on.
When you file the bugzilla, would you kindly post the link for it here?
Perhaps a workaround is a cron job that runs every fifty minutes and touches every file under /tmp .
On 04/24/2014 04:24 PM, Michael Hennebry issued this missive:
Perhaps a workaround is a cron job that runs every fifty minutes and touches every file under /tmp .
First, make sure the systemd stuff that cleans it is disabled:
systemctl stop systemd-tmpfiles-clean.service systemctl disable systemd-tmpfiles-clean.service systemctl mask systemd-tmpfiles-clean.service
See if that has any affect. Also note that by default, /tmp is now a tmpfs (RAMdisk) thing, so any info in /tmp will NOT survive a reboot. To disable that and return /tmp to something reasonable and usable, do:
systemctl disable tmp.mount systemctl mask tmp.mount
Reboot and verify that /tmp is either just a directory or that a normal filesystem is mounted there. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Squawk! Pieces of Seven! Pieces of Seven! Parity Error! - ----------------------------------------------------------------------
Allegedly, on or about 24 April 2014, Rick Stevens sent:
Also note that by default, /tmp is now a tmpfs (RAMdisk) thing, so any info in /tmp will NOT survive a reboot.
What happens when you run out of RAM? Could that be the cause of /tmp being prematurely wiped out?
On 04/25/2014 06:05 AM, Tim issued this missive:
Allegedly, on or about 24 April 2014, Rick Stevens sent:
Also note that by default, /tmp is now a tmpfs (RAMdisk) thing, so any info in /tmp will NOT survive a reboot.
What happens when you run out of RAM? Could that be the cause of /tmp being prematurely wiped out?
No, but IIRC the tmpfs filesystem created and mounted on /tmp is 50% of your system RAM. Once that is committed, it's done. It won't use up all of your RAM and /tmp won't get any bigger than that, but then again half of your available RAM is no longer available for program usage.
IMHO using a tmpfs for /tmp is a spectacularly stupid thing to do. How it got by the vetting process is beyond me. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Beware of programmers who carry screwdrivers - ----------------------------------------------------------------------
Rick Stevens writes:
IMHO using a tmpfs for /tmp is a spectacularly stupid thing to do. How it got by the vetting process is beyond me.
I agree. A number of distributions are doing it, however. If you have lots of RAM, I guess it's okay, and it certainly would be faster for /tmp access.
IMHO using a tmpfs for /tmp is a spectacularly stupid thing to do. How it got by the vetting process is beyond me.
There shouldn't be anything that uses anything beyond a negligible amount of storage. Remember that there is no guarantee that /tmp data is preserved between invocations. Why would there ever be a significant amount of data stored there?
From two F20 systems:
for i in $(mount -l | grep '^tmpfs' | grep -o '/[^ ]*'); do sudo du -hs $i; done
Server: 0 /dev/shm 720K /run 0 /sys/fs/cgroup 0 /tmp
Workstation: 3.8M /dev/shm 1.1M /run 0 /sys/fs/cgroup 652K /tmp
There are a number of locations for temporary files, which provide different features. /tmp is on tmpfs because the FSH standard defines that directory as so transitory that it shouldn't matter. For those that don't want to use tmpfs, use /var/tmp/. Complaints about this sort of thing are either a failure of the user or software developer to keep up to date on the file system standards.
On Fri, Apr 25, 2014 at 12:03 PM, Rick Stevens ricks@alldigital.com wrote:
On 04/25/2014 06:05 AM, Tim issued this missive:
Allegedly, on or about 24 April 2014, Rick Stevens sent:
Also note that by default, /tmp is now a tmpfs (RAMdisk) thing, so any info in /tmp will NOT survive a reboot.
What happens when you run out of RAM? Could that be the cause of /tmp being prematurely wiped out?
No, but IIRC the tmpfs filesystem created and mounted on /tmp is 50% of your system RAM. Once that is committed, it's done. It won't use up all of your RAM and /tmp won't get any bigger than that, but then again half of your available RAM is no longer available for program usage.
IMHO using a tmpfs for /tmp is a spectacularly stupid thing to do. How it got by the vetting process is beyond me.
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
-Beware of programmers who carry screwdrivers -
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Justin Brown writes:
Complaints about this sort of thing are either a failure of the user or software developer to keep up to date on the file system standards.
My understanding was that file system hierarchy was supposed to be about how files are arranged so that they would be consistent across distributions. It should not be about whether we put file systems in RAM or on RAID or on any particular medium.
To mandate RAM allocation in this way will take many people, including myself, by surprise. For many users, 50% of RAM is a *lot* of RAM, with serious performance impacts, and I do not do this on my systems.
To mandate RAM allocation in this way will take many people, including myself, by surprise.
It's been this way on Fedora for over two years (https://fedoraproject.org/wiki/Features/tmp-on-tmpfs). Most other new distributions do it, too. From that feature page, "Solaris has been doing this since 1994. (Much like other Unixes, too.) Debian's next release defaults to tmpfs on /tmp, too. ArchLinux defaults to this as well. Ubuntu has plans for their 12.10 release." There's basically no disagreement about it among the distributions.
50% of RAM is a *lot* of RAM, with serious performance impacts, and I do not do this on my systems.
You know that it's not a static allocation, right? If you're only using a few KB of /tmp, the file system is only consume a few KB. 50% is just the absolute maximum that can be used, and it's a default which can be controlled via mount option (or /lib/systemd/system/tmp.mount Options=size=... with systemd).
I think you should do some investigation on how tmpfs works, and the benefits of this configuration before jumping to incorrect conclusions.
On Fri, Apr 25, 2014 at 12:51 PM, benfell@parts-unknown.org wrote:
Justin Brown writes:
Complaints about this sort of thing are either a failure of the user or software developer to keep up to date on the file system standards.
My understanding was that file system hierarchy was supposed to be about how files are arranged so that they would be consistent across distributions. It should not be about whether we put file systems in RAM or on RAID or on any particular medium.
To mandate RAM allocation in this way will take many people, including myself, by surprise. For many users, 50% of RAM is a *lot* of RAM, with serious performance impacts, and I do not do this on my systems.
-- David Benfell See https://parts-unknown.org/node/2 if you do not understand the attachment.
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Justin Brown writes:
50% is just the absolute maximum that can be used, and it's a default which can be controlled via mount option (or /lib/systemd/system/tmp.mount Options=size=... with systemd).
Thank you for telling me what to kill.
I have way too much trouble with my systems being swap-bound to tolerate any allocation of the sort.
David,
This doesn't make sense. Tmpfs can be swapped out, so you're gaining absolutely nothing and taking on a development and maintenance burden. IO for /tmp would have to come from disk when using tmpfs (in the case of heavy swapping) or a traditional file system either way. In the end, we're probably talking about 1MiB combined between the 4 tmpfs file systems on Fedora.
On Fri, Apr 25, 2014 at 1:47 PM, benfell@parts-unknown.org wrote:
Justin Brown writes:
50% is just the absolute maximum that can be used, and it's a default which can be controlled via mount option (or /lib/systemd/system/tmp.mount Options=size=... with systemd).
Thank you for telling me what to kill.
I have way too much trouble with my systems being swap-bound to tolerate any allocation of the sort.
-- David Benfell See https://parts-unknown.org/node/2 if you do not understand the attachment.
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Justin Brown writes:
David,
This doesn't make sense. Tmpfs can be swapped out, so you're gaining absolutely nothing and taking on a development and maintenance burden. IO for /tmp would have to come from disk when using tmpfs (in the case of heavy swapping) or a traditional file system either way. In the end, we're probably talking about 1MiB combined between the 4 tmpfs file systems on Fedora.
It doesn't have to make sense to you.
To me, the idea of sticking /tmp in RAM is absolutely bizarre. And the fact that it can be swapped is no help: It's one more thing to swap. I want *less* swapping, not more.
On 04/25/2014 02:15 PM, benfell@parts-unknown.org wrote:
To me, the idea of sticking /tmp in RAM is absolutely bizarre. And the fact that it can be swapped is no help: It's one more thing to swap. I want *less* swapping, not more.
How much swapping is your system doing? Give us the results of free -m so that we can get an idea how bad things are.
Joe Zeff writes:
On 04/25/2014 02:15 PM, benfell@parts-unknown.org wrote:
To me, the idea of sticking /tmp in RAM is absolutely bizarre. And the fact that it can be swapped is no help: It's one more thing to swap. I want *less* swapping, not more.
How much swapping is your system doing? Give us the results of free -m so that we can get an idea how bad things are.
And this is at a relatively slack time. I'm not noticing impaired performance right now:
[root@munich]/etc/ejabberd# free -m total used free shared buffers cached Mem: 3254 3128 125 1 9 151 -/+ buffers/cache: 2967 286 Swap: 9486 5032 4454
On 04/25/2014 04:36 PM, benfell@parts-unknown.org wrote:
And this is at a relatively slack time. I'm not noticing impaired performance right now:
[root@munich]/etc/ejabberd# free -m total used free shared buffers cached Mem: 3254 3128 125 1 9 151 -/+ buffers/cache: 2967 286 Swap: 9486 5032 4454
I've always disliked throwing somebody else's money at a problem, but I do have to ask: is it practical for you to upgrade your RAM? If your computer can handle more than 4GB and you don't want to do a complete re-install to go to a 64-bit system, you can always do what I did: install a PAE kernel (if you don't already have one) because that allows a 32-bit system to access up to 64 BG of RAM. The process is quite simple and I'd be glad to walk you through it if and when you need it.
Joe Zeff writes:
On 04/25/2014 04:36 PM, benfell@parts-unknown.org wrote:
And this is at a relatively slack time. I'm not noticing impaired performance right now:
[root@munich]/etc/ejabberd# free -m total used free shared buffers cached Mem: 3254 3128 125 1 9 151 -/+ buffers/cache: 2967 286 Swap: 9486 5032 4454
I've always disliked throwing somebody else's money at a problem, but I do have to ask: is it practical for you to upgrade your RAM? If your computer can handle more than 4GB and you don't want to do a complete re-install to go to a 64-bit system, you can always do what I did: install a PAE kernel (if you don't already have one) because that allows a 32-bit system to access up to 64 BG of RAM. The process is quite simple and I'd be glad to walk you through it if and when you need it.
It's already a 64-bit system. I am hoping and expecting to be able to increase the RAM later this year. But I can't, yet: It's a dedicated server in Munich that I'm renting month-to-month and I have to be able to swing the rent. ;-)
On 04/25/2014 05:08 PM, benfell@parts-unknown.org wrote:
It's already a 64-bit system. I am hoping and expecting to be able to increase the RAM later this year. But I can't, yet: It's a dedicated server in Munich that I'm renting month-to-month and I have to be able to swing the rent. ;-)
Rent, of course must come first, which is why I asked if an upgrade were practical. Make sure you know how much the RAM costs, both to buy and to get installed if you're not doing it yourself, and put the upgrade onto your wish list.
On Fri, 2014-04-25 at 10:03 -0700, Rick Stevens wrote:
No, but IIRC the tmpfs filesystem created and mounted on /tmp is 50% of your system RAM. Once that is committed, it's done. It won't use up all of your RAM and /tmp won't get any bigger than that, but then again half of your available RAM is no longer available for program usage.
Seems extreme. How many temporary files are that big? Most of the stuff I see in it are merely a few kilobytes. However, I agree with the following, for a particular reason, not just in general (which I do, as well):
IMHO using a tmpfs for /tmp is a spectacularly stupid thing to do. How it got by the vetting process is beyond me.
Those of us who've gone to burn a CD or DVD, only to have the program mysteriously fail (i.e. no sane error message was ever shown), because it wanted to create the ISO in /tmp before it burnt it, but we never had enough RAM to create an entire ISO file, in the first place.
It strikes me that programs that create small temporary files ought to be putting them in an appropriate place, perhaps a /tmp that's known to be in RAM, so long as they can cope with their temporary files disappearing on them. But, those things that may need to keep a temporary file around for a while, ought to be doing it space that's known to be non-volatile. And those programs that create large temporary files ought to be putting them where it's known to be non-RAM, such as inside /var/spool.
On 04/26/2014 04:45 AM, Tim wrote:
On Fri, 2014-04-25 at 10:03 -0700, Rick Stevens wrote:
No, but IIRC the tmpfs filesystem created and mounted on /tmp is 50% of your system RAM. Once that is committed, it's done. It won't use up all of your RAM and /tmp won't get any bigger than that, but then again half of your available RAM is no longer available for program usage.
Seems extreme. How many temporary files are that big?
/tmp is system-wide writable, i.e. any arbitrary users and any arbitrary process can create an arbitrary number of files in /tmp.
As /tmp had been the traditional unlimited sink for temporary files, many tools create temporary files of arbitrary size in /tmp.
These tools will occasionally fail to work with TmpOnTmpfs and may cause system malfunctions, esp. on small RAM systems.
Ralf
On 4-25-14 10:03:11 Rick Stevens wrote:
No, but IIRC the tmpfs filesystem created and mounted on /tmp is 50% of your system RAM. Once that is committed, it's done. It won't use up all of your RAM and /tmp won't get any bigger than that, but then again half of your available RAM is no longer available for program usage.
That's not true. Swap will come into play and unreferenced data in the /tmp files will be paged out in favor of claiming that memory for other uses.
It's still a win, however. If and when some file that was paged out is opened or read again, it will be paged back in. That can be faster than normal file I/O.
IMHO using a tmpfs for /tmp is a spectacularly stupid thing to do. How it got by the vetting process is beyond me.
This was discussed in great detail before the change was made.
On 26.04.2014, Garry T. Williams wrote:
That's not true. Swap will come into play and unreferenced data in the /tmp files will be paged out in favor of claiming that memory for other uses.
Did you actually try?
[htd@kiera ~]$ dd if=/dev/zero of=/tmp/bigfile bs=1M count=3000 dd: error writing ‘/tmp/bigfile’: No space left on device 2048+0 records in 2047+0 records out 2147450880 bytes (2.1 GB) copied, 0.920556 s, 2.3 GB/s
[htd@kiera ~]$ free -m total used free shared buffers cached Mem: 3745 1562 2183 0 0 773 -/+ buffers/cache: 787 2957 Swap: 8191 0 8191
I have 4 GB of memory in my machine, and mount defaults to "size=50%" (= 2GB). I have been running /tmp as a tmpfs a long time, because the harddisk is a SSD. What happens can you see above: it creates a 2 GB file and aborts for the next 1 GB. The machine has 8 GB of swap, and nothing of it was used.
Disclaimer: this is not a rant against having /tmp using tmpfs. I'm aware of the limitations, and have only encountered positive experiences so far.
On 4-26-14 09:43:41 Heinz Diehl wrote:
On 26.04.2014, Garry T. Williams wrote:
That's not true. Swap will come into play and unreferenced data in the /tmp files will be paged out in favor of claiming that memory for other uses.
Did you actually try?
[htd@kiera ~]$ dd if=/dev/zero of=/tmp/bigfile bs=1M count=3000 dd: error writing ‘/tmp/bigfile’: No space left on device 2048+0 records in 2047+0 records out 2147450880 bytes (2.1 GB) copied, 0.920556 s, 2.3 GB/s
[htd@kiera ~]$ free -m total used free shared buffers cached Mem: 3745 1562 2183 0 0 773 -/+ buffers/cache: 787 2957 Swap: 8191 0 8191
I have 4 GB of memory in my machine, and mount defaults to "size=50%" (= 2GB). I have been running /tmp as a tmpfs a long time, because the harddisk is a SSD. What happens can you see above: it creates a 2 GB file and aborts for the next 1 GB. The machine has 8 GB of swap, and nothing of it was used.
When another process requires memory in excess of what is immediately available, the unreferenced file(s) in /tmp can be paged out to accommodate the request. If memory pressure is absent, no paging will occur. There is no pressure here.
(I only wanted to correct the claim that placing files in /tmp would encumber main memory to the detriment of other processes. That is not so as long as the system can page out unneeded memory.)
Disclaimer: this is not a rant against having /tmp using tmpfs. I'm aware of the limitations, and have only encountered positive experiences so far.
This is my experience, too.
On Fri, 25 Apr 2014, Tim wrote:
Allegedly, on or about 24 April 2014, Rick Stevens sent:
Also note that by default, /tmp is now a tmpfs (RAMdisk) thing, so any info in /tmp will NOT survive a reboot.
What happens when you run out of RAM? Could that be the cause of /tmp being prematurely wiped out?
Probably not. OP says that files are removed after an hour like clockwork.:wq
On 18.04.2014 01:24, Tucker wrote:
Presumably, removing all the files in those directories would do the same but it appears that it's still purging /tmp. Does systemd-tmpfiles require a reload/restart before it picks up changes? If so, that conveniently requires a reboot since it ignores manual anything. I'd love to be able to completely kill it but my familiarity with systemd is very limited. Anyone care to venture a guess about what would happen if I removed the executable bit from the binary?
# systemctl mask systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Working?
poma
I remember when Linux used to be easy... ;)
That's perfect. I actually just made it to that part of the man page and I _never_ would have read that section and thought "this will stop it!" Much appreciated.
On Thu, Apr 17, 2014 at 4:45 PM, poma pomidorabelisima@gmail.com wrote:
On 18.04.2014 01:24, Tucker wrote:
Presumably, removing all the files in those directories would do the same but it appears that it's still purging /tmp. Does systemd-tmpfiles
require
a reload/restart before it picks up changes? If so, that conveniently requires a reboot since it ignores manual anything. I'd love to be able
to
completely kill it but my familiarity with systemd is very limited.
Anyone
care to venture a guess about what would happen if I removed the
executable
bit from the binary?
# systemctl mask systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Working?
poma
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
-
Andrew Haley -
Chris Murphy -
David Benfell -
Ed Greshko -
Garry Williams -
Heinz Diehl -
Joe Zeff -
Justin Brown -
Matthew Miller -
Michael Hennebry -
poma -
Rahul Sundaram -
Ralf Corsepius -
Rick Stevens -
Tim -
Tucker