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
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
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?
--
[tim@localhost ~]$
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
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
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
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
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
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
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
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
On 04/25/2014 02:15 PM, benf...@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
On 04/25/2014 04:36 PM, benf...@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 sharedbuffers cached
Mem: 3254 3128
Joe Zeff writes:
On 04/25/2014 04:36 PM, benf...@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 sharedbuffers cached
Mem: 3254
On 04/25/2014 05:08 PM, benf...@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. ;-)
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
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
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
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
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
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
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
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,
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?
--
Getting tired of non-Fedora discussions and
Perhaps a workaround is a cron job that runs every
fifty minutes and touches every file under /tmp .
--
Michael henne...@web.cs.ndsu.nodak.edu
SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then. -- John
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
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
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
On Apr 20, 2014, at 2:00 AM, Andrew Haley a...@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
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
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
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
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
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
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 pomidorabelis...@gmail.com wrote:
On 18.04.2014
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,
37 matches
Mail list logo
