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
isable 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 co
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/03/2012 11:55 AM, Geoffrey Leach wrote:
> Fedora (not just 16) leaves junk in /tmp. It's also using some of
> that junk, for example keyring-PRgjGV/.
>
> So what's the best way to reduce the clutter? Is there a service?
I like to mount /tmp as t
On Sat, 2012-03-03 at 19:36 +, James Wilkinson wrote:
> One option is tmpfs. Put something like this in /etc/fstab:
> none/tmptmpfs nodev,noexec 0 0
> and everything in /tmp will be deleted whenever the system is rebooted
> or powered down (unless you h
Geoffrey Leach wrote:
> Fedora (not just 16) leaves junk in /tmp. It's also using some of that
> junk, for example keyring-PRgjGV/.
>
> So what's the best way to reduce the clutter? Is there a service?
One option is tmpfs. Put something like this in /etc/fstab:
none/tmp
Am 03.03.2012 18:35, schrieb Frank Murphy:
> On 03/03/12 17:18, Reindl Harald wrote:
>> cat /etc/cron.daily/tmpwatch
>>
>> #! /bin/sh
>>
>> flags=-umc
>>
>> /usr/sbin/tmpwatch "$flags" -x/tmp/.X11-unix -x /tmp/.XIM-unix \
>> -x/tmp/.font-unix -x/tmp/.ICE-unix -x/tmp/.Test-unix \
>>
On 03/03/12 17:18, Reindl Harald wrote:
cat /etc/cron.daily/tmpwatch
#! /bin/sh
flags=-umc
/usr/sbin/tmpwatch "$flags" -x/tmp/.X11-unix -x /tmp/.XIM-unix \
-x/tmp/.font-unix -x/tmp/.ICE-unix -x/tmp/.Test-unix \
-X '/tmp/hsperfdata_*' 1d /tmp
/usr/sbin/tmpwatch "$flags" 1d /va
On 3 March 2012 16:55, Geoffrey Leach wrote:
> Fedora (not just 16) leaves junk in /tmp. It's also using some of that
> junk, for example keyring-PRgjGV/.
>
Another instance of a Linux regression, IMHO. Used to be anything in /tmp
was supposedly safe to be erased on boot, and often was. Then a
Am 03.03.2012 17:55, schrieb Geoffrey Leach:
> Fedora (not just 16) leaves junk in /tmp. It's also using some of that
> junk, for example keyring-PRgjGV/.
>
> So what's the best way to reduce the clutter? Is there a service?
as default there are 30d instead my 1d
[root@srv-rhsoft:~]$ cat /etc
Fedora (not just 16) leaves junk in /tmp. It's also using some of that
junk, for example keyring-PRgjGV/.
So what's the best way to reduce the clutter? Is there a service?
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproje
Tim:
>> Not quite... It will delete not recently looked at files, whether you
>> actually used them or not. It's an important distinction, here's why:
Adalbert Prokop:
> I did not want to exaggerate the distinction between
> creation/modification/access time - simplifications are helpful in
> ex
On Wed, 2010-03-31 at 16:28 -0400, Tom H wrote:
> Or turn /tmp into a tmpfs mount.
That can come back to bite you when you go to burn a CD or DVD, the
burner uses /tmp to make temp files, and you run out real RAM.
--
[...@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686
Don't send private repl
Wolfgang S. Rupprecht wrote:
> Gregory Hosler writes:
>> On 03/31/2010 09:52 PM, Maurizio Marini wrote:
>>> Hi there
>>> i need a cron script that cleans every day crap into /tmp
>>> I have there a lot of temp files but i dunno which ones can be safely
>>> wiped,
>>> and it is very time comsumin
>>> i need a cron script that cleans every day crap into /tmp
>>> I have there a lot of temp files but i dunno which ones can be safely wiped,
>>> and it is very time comsuming job, too.
>> There already is a cron that will delete file out of /tmp that are 10 days
>> old.
> In addition, at shutd
Gregory Hosler writes:
> On 03/31/2010 09:52 PM, Maurizio Marini wrote:
>> Hi there
>> i need a cron script that cleans every day crap into /tmp
>> I have there a lot of temp files but i dunno which ones can be safely wiped,
>> and it is very time comsuming job, too.
>> Any script written by som
Am 31.03.2010 16:51, schrieb Tim:
Hi!
> On Wed, 2010-03-31 at 15:58 +0200, Adalbert Prokop wrote:
>> There is no need to reinvent the wheel. Fedora comes with tmpwatch,
>> which does exactly what you want - scans /tmp (and possibly other
>> directories) and deletes unused files.
> Not quite...
On 31 March 2010 07:51, Tim wrote:
> On Wed, 2010-03-31 at 15:58 +0200, Adalbert Prokop wrote:
>> There is no need to reinvent the wheel. Fedora comes with tmpwatch,
>> which does exactly what you want - scans /tmp (and possibly other
>> directories) and deletes unused files.
>
> Not quite... It
On Wed, 2010-03-31 at 15:58 +0200, Adalbert Prokop wrote:
> There is no need to reinvent the wheel. Fedora comes with tmpwatch,
> which does exactly what you want - scans /tmp (and possibly other
> directories) and deletes unused files.
Not quite... It will delete not recently looked at files,
Am 31.03.2010 15:52, schrieb Maurizio Marini:
Hi!
> i need a cron script that cleans every day crap into /tmp
> I have there a lot of temp files but i dunno which ones can be safely wiped,
> and it is very time comsuming job, too.
> Any script written by someone of you will be very apreciated :)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/31/2010 09:52 PM, Maurizio Marini wrote:
> Hi there
> i need a cron script that cleans every day crap into /tmp
> I have there a lot of temp files but i dunno which ones can be safely wiped,
> and it is very time comsuming job, too.
> Any script
Hi there
i need a cron script that cleans every day crap into /tmp
I have there a lot of temp files but i dunno which ones can be safely wiped,
and it is very time comsuming job, too.
Any script written by someone of you will be very apreciated :)
tia
Maurizio
--
users mailing list
users@lists.fe
59 matches
Mail list logo
