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
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 w
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 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 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 R
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. ;-)
Rent,
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 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 31281
Joe Zeff writes:
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
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 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 wipe
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 w
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 pr
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-b
> 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 sin
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 ac
> 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 wou
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.
--
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
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 ~]$ u
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
system
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." -- Joh
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
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
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
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
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
> >> indicat
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 o
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
> applic
On Apr 20, 2014, at 2:00 AM, Andrew Haley 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 thin
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 Thi
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,
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/* directori
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 wrote:
> On 18.04.2014 01:24, Tucker 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
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 wrot
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-c
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
co
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 problem
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
40 matches
Mail list logo
