/tmp is filling up rapidly. I'm guessing that it would be safe enough to delete everything dated previous to the last bootup. Am I right?
Anne
Anne Wilson wrote:
/tmp is filling up rapidly. I'm guessing that it would be safe enough to delete everything dated previous to the last bootup. Am I right?
The most logical question is, what is /tmp filling up with? I can't say that in a normally operating system I've seen /tmp filling up "rapidly" without a cause and I'm not the one to go willy-nilly deleting things without known why they are being created.
On Sunday 07 January 2007 11:03, Ed Greshko wrote:
Anne Wilson wrote:
/tmp is filling up rapidly. I'm guessing that it would be safe enough to delete everything dated previous to the last bootup. Am I right?
The most logical question is, what is /tmp filling up with? I can't say that in a normally operating system I've seen /tmp filling up "rapidly" without a cause and I'm not the one to go willy-nilly deleting things without known why they are being created.
Duh! I mis-read the logfile line. It's not really filling up, though there are things that I think should be deleted.
I think that most of them are print-related. There are empty directories with names like autoKNJXsu, and lots of 19.1K files that contain the line '*% You may save this file as 'HP-DeskJet_990C-hpijs.ppd'. There are also some files that seem to be previews of failed print jobs when I was setting up a remote printer.
These (print) are the ones I propose deleting. I'd leave anything that I had doubts about, although socket files and mapping files exist (often 0 bytes) with dates in November and December - this is a box that is shut down most nights.
Anne
Around 11:20am on Sunday, January 07, 2007 (UK time), Anne Wilson scrawled:
On Sunday 07 January 2007 11:03, Ed Greshko wrote:
Anne Wilson wrote:
/tmp is filling up rapidly. I'm guessing that it would be safe enough to delete everything dated previous to the last bootup. Am I right?
The most logical question is, what is /tmp filling up with? I can't say that in a normally operating system I've seen /tmp filling up "rapidly" without a cause and I'm not the one to go willy-nilly deleting things without known why they are being created.
Duh! I mis-read the logfile line. It's not really filling up, though there are things that I think should be deleted.
Anne,
I run the following command in a cron job:
tmpwatch --mtime --verbose --verbose 168 /tmp
You may not want the --verbose, and check the manpage for the --mtime option, but basically this deletes all files in /tmp that have not been modified for 168 hours or more.
Steve
On Sunday 07 January 2007 11:33, Steve Searle wrote:
Around 11:20am on Sunday, January 07, 2007 (UK time), Anne Wilson scrawled:
On Sunday 07 January 2007 11:03, Ed Greshko wrote:
Anne Wilson wrote:
/tmp is filling up rapidly. I'm guessing that it would be safe enough to delete everything dated previous to the last bootup. Am I right?
The most logical question is, what is /tmp filling up with? I can't say that in a normally operating system I've seen /tmp filling up "rapidly" without a cause and I'm not the one to go willy-nilly deleting things without known why they are being created.
Duh! I mis-read the logfile line. It's not really filling up, though there are things that I think should be deleted.
Anne,
I run the following command in a cron job:
tmpwatch --mtime --verbose --verbose 168 /tmp
You may not want the --verbose, and check the manpage for the --mtime option, but basically this deletes all files in /tmp that have not been modified for 168 hours or more.
Excellent idea, Steve. Thanks. I've set it up, with --verbose for the moment.
Anne
Around 12:33pm on Sunday, January 07, 2007 (UK time), Anne Wilson scrawled:
Excellent idea, Steve. Thanks. I've set it up, with --verbose for the moment.
You may well have realised anyway, but you need to run it as root for it to delete the files created by any user.
Steve
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
On Sunday 07 January 2007 12:36, Steve Searle wrote:
Around 12:33pm on Sunday, January 07, 2007 (UK time), Anne Wilson scrawled:
Excellent idea, Steve. Thanks. I've set it up, with --verbose for the moment.
You may well have realised anyway, but you need to run it as root for it to delete the files created by any user.
Yes, I did remember, but thanks for reminding me anyway :-)
Anne
On Sunday 07 January 2007 11:33, Steve Searle wrote:
Around 11:20am on Sunday, January 07, 2007 (UK time), Anne Wilson scrawled:
On Sunday 07 January 2007 11:03, Ed Greshko wrote:
Anne Wilson wrote:
/tmp is filling up rapidly. I'm guessing that it would be safe enough to delete everything dated previous to the last bootup. Am I right?
The most logical question is, what is /tmp filling up with? I can't say that in a normally operating system I've seen /tmp filling up "rapidly" without a cause and I'm not the one to go willy-nilly deleting things without known why they are being created.
Duh! I mis-read the logfile line. It's not really filling up, though there are things that I think should be deleted.
Anne,
I run the following command in a cron job:
tmpwatch --mtime --verbose --verbose 168 /tmp
You may not want the --verbose, and check the manpage for the --mtime option, but basically this deletes all files in /tmp that have not been modified for 168 hours or more.
I have a problem, Steve. Running that command from a root konsole works fine, so I set it to run as a cron job every Wednesday. Now I find that from both boxes where I set this up I'm getting root emails that say
/bin/sh: tmpwatch: command not found
What could be wonrg?
Anne
Anne Wilson wrote:
I have a problem, Steve. Running that command from a root konsole works fine, so I set it to run as a cron job every Wednesday. Now I find that from both boxes where I set this up I'm getting root emails that say
/bin/sh: tmpwatch: command not found
What could be wonrg?
Use the full pathname. /usr/sbin/tmpwatch
On Wednesday 10 January 2007 11:48, Ed Greshko wrote:
Anne Wilson wrote:
I have a problem, Steve. Running that command from a root konsole works fine, so I set it to run as a cron job every Wednesday. Now I find that from both boxes where I set this up I'm getting root emails that say
/bin/sh: tmpwatch: command not found
What could be wonrg?
Use the full pathname. /usr/sbin/tmpwatch
Thanks, Ed. That seems to have cured it - at least 'Run now' worked fine. I just assumed that it would be on root's path, so didn't need the full pathname.
Anne
On Wed, Jan 10, 2007 at 12:03:47PM +0000, Anne Wilson wrote:
On Wednesday 10 January 2007 11:48, Ed Greshko wrote:
Anne Wilson wrote:
I have a problem, Steve. Running that command from a root konsole works fine, so I set it to run as a cron job every Wednesday. Now I find that from both boxes where I set this up I'm getting root emails that say
/bin/sh: tmpwatch: command not found
What could be wonrg?
Use the full pathname. /usr/sbin/tmpwatch
Thanks, Ed. That seems to have cured it - at least 'Run now' worked fine. I just assumed that it would be on root's path, so didn't need the full pathname.
Anne
Anne:
You may find it helpful to look at the man page for crontab(5) (man 5 crontab), as it tells how to set up a proper environment for cron jobs. The implication is that you don't have a full envrionment set up when cron runs a job.
On Wednesday 10 January 2007 16:38, fredex wrote:
On Wed, Jan 10, 2007 at 12:03:47PM +0000, Anne Wilson wrote:
On Wednesday 10 January 2007 11:48, Ed Greshko wrote:
Anne Wilson wrote:
I have a problem, Steve. Running that command from a root konsole works fine, so I set it to run as a cron job every Wednesday. Now I find that from both boxes where I set this up I'm getting root emails that say
/bin/sh: tmpwatch: command not found
What could be wonrg?
Use the full pathname. /usr/sbin/tmpwatch
Thanks, Ed. That seems to have cured it - at least 'Run now' worked fine. I just assumed that it would be on root's path, so didn't need the full pathname.
Anne
Anne:
You may find it helpful to look at the man page for crontab(5) (man 5 crontab), as it tells how to set up a proper environment for cron jobs. The implication is that you don't have a full envrionment set up when cron runs a job.
Thanks, Fred. Someone sent me an off-list message to that effect. Another new concept for me :-)
Anne
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Anne Wilson wrote:
On Sunday 07 January 2007 11:33, Steve Searle wrote:
Around 11:20am on Sunday, January 07, 2007 (UK time), Anne Wilson scrawled:
On Sunday 07 January 2007 11:03, Ed Greshko wrote:
Anne Wilson wrote:
/tmp is filling up rapidly. I'm guessing that it would be safe enough to delete everything dated previous to the last bootup. Am I right?
The most logical question is, what is /tmp filling up with? I can't say that in a normally operating system I've seen /tmp filling up "rapidly" without a cause and I'm not the one to go willy-nilly deleting things without known why they are being created.
Duh! I mis-read the logfile line. It's not really filling up, though there are things that I think should be deleted.
Anne,
I run the following command in a cron job:
tmpwatch --mtime --verbose --verbose 168 /tmp
You may not want the --verbose, and check the manpage for the --mtime option, but basically this deletes all files in /tmp that have not been modified for 168 hours or more.
I have a problem, Steve. Running that command from a root konsole works fine, so I set it to run as a cron job every Wednesday. Now I find that from both boxes where I set this up I'm getting root emails that say
/bin/sh: tmpwatch: command not found
What could be wonrg?
Anne
$ locate tmpwatch /etc/cron.daily/tmpwatch /usr/sbin/tmpwatch /usr/share/man/man8/tmpwatch.8.gz
What happens if you give it the full path?
( /usr/sbin/tmpwatch instead of just tmpwatch )
ciao, furlan
- --
Music: http://www.myspace.com/acidredux
Links: http://del.icio.us/furlan
Home: http://flprim.us/index.html
"Play--more than piety, more than charity or vigilance--is what allows human beings to transcend evil." - -- Tom Robbins (Jitterbug Perfume)
On Thursday 11 January 2007 16:44, magicus wrote:
$ locate tmpwatch /etc/cron.daily/tmpwatch /usr/sbin/tmpwatch /usr/share/man/man8/tmpwatch.8.gz
What happens if you give it the full path?
( /usr/sbin/tmpwatch instead of just tmpwatch )
Hi, furlan. Yes, that's what was needed. I had not understood that root didn't have access to its path when running the command in a cron job. 'Run now' worked, so hopefully, next time it runs as scheduled on Wednesday it should run without problems.
I do like the cron emails. Such a comfort :-)
Anne
Anne Wilson wrote:
On Sunday 07 January 2007 11:33, Steve Searle wrote:
Around 11:20am on Sunday, January 07, 2007 (UK time), Anne Wilson scrawled:
On Sunday 07 January 2007 11:03, Ed Greshko wrote:
Anne Wilson wrote:
/tmp is filling up rapidly. I'm guessing that it would be safe enough to delete everything dated previous to the last bootup. Am I right?
The most logical question is, what is /tmp filling up with? I can't say that in a normally operating system I've seen /tmp filling up "rapidly" without a cause and I'm not the one to go willy-nilly deleting things without known why they are being created.
Duh! I mis-read the logfile line. It's not really filling up, though there are things that I think should be deleted.
Anne,
I run the following command in a cron job:
tmpwatch --mtime --verbose --verbose 168 /tmp
You may not want the --verbose, and check the manpage for the --mtime option, but basically this deletes all files in /tmp that have not been modified for 168 hours or more.
I have a problem, Steve. Running that command from a root konsole works fine, so I set it to run as a cron job every Wednesday. Now I find that from both boxes where I set this up I'm getting root emails that say
/bin/sh: tmpwatch: command not found
What could be wonrg?
Anne
I personally prefer to use tmpfs
in /etc/fstab :
tmpfs /tmp tmpfs nosuid,noexec,size=256m,mode=1777 0 0
That way /tmp does not use any physical disk space - and is wiped every time I reboot.
size=256m is optional - w/o it though, it can use up to half of your physical ram. A 256m /tmp is more than plenty.
The only drawback - if you download files larger than the available space in the /tmp filesystem via firefox - the download will fail because firefox assembles it in /tmp. You can change that in Firefox preferences - but I prefer to grab large files via wget rather than firefox download manager.
With a 256 MB /tmp - I rarely use more than 1% of it. With /tmp in memory - the disk arm doesn't have to move to write/read temp files, they are read out of memory.
Michael A. Peters wrote:
Anne Wilson wrote:
On Sunday 07 January 2007 11:33, Steve Searle wrote:
Around 11:20am on Sunday, January 07, 2007 (UK time), Anne Wilson scrawled:
On Sunday 07 January 2007 11:03, Ed Greshko wrote:
Anne Wilson wrote:
/tmp is filling up rapidly. I'm guessing that it would be safe enough to delete everything dated previous to the last bootup. Am I right?
The most logical question is, what is /tmp filling up with? I can't say that in a normally operating system I've seen /tmp filling up "rapidly" without a cause and I'm not the one to go willy-nilly deleting things without known why they are being created.
Duh! I mis-read the logfile line. It's not really filling up, though there are things that I think should be deleted.
Anne,
I run the following command in a cron job:
tmpwatch --mtime --verbose --verbose 168 /tmpYou may not want the --verbose, and check the manpage for the --mtime option, but basically this deletes all files in /tmp that have not been modified for 168 hours or more.
I have a problem, Steve. Running that command from a root konsole works fine, so I set it to run as a cron job every Wednesday. Now I find that from both boxes where I set this up I'm getting root emails that say
/bin/sh: tmpwatch: command not found
What could be wonrg?
tmpwatch is /usr/sbin/tmpwatch. Is /usr/sbin in your path in the cronjob?
Anne
I personally prefer to use tmpfs
in /etc/fstab :
tmpfs /tmp tmpfs nosuid,noexec,size=256m,mode=1777 0 0
That way /tmp does not use any physical disk space - and is wiped every time I reboot.
size=256m is optional - w/o it though, it can use up to half of your physical ram. A 256m /tmp is more than plenty.
The only drawback - if you download files larger than the available space in the /tmp filesystem via firefox - the download will fail because firefox assembles it in /tmp. You can change that in Firefox preferences - but I prefer to grab large files via wget rather than firefox download manager.
With a 256 MB /tmp - I rarely use more than 1% of it. With /tmp in memory - the disk arm doesn't have to move to write/read temp files, they are read out of memory.
*doh*
Sorry for the noise - I flipped the message sorting on my client accidentally and didn't realize this was such an old thread
Anne Wilson schrieb:
/tmp is filling up rapidly. I'm guessing that it would be safe enough to delete everything dated previous to the last bootup. Am I right?
Anne
It should actually be easier to go to runlevel 1 and remove everything in /tmp. It's very unlikely that there are any processes left that need /tmp in runlevel 1.
You should investigate, why you /tmp in filling up rapidly. Maybe this command helps to find the file/directory, that consumes most of the disk space:
du -sm * | sort -n
du -sm .??* | sort -n (for all hidden files and directories)
greets Boris
On Sunday 07 January 2007 19:38, Boris Glawe wrote:
Anne Wilson schrieb:
/tmp is filling up rapidly. I'm guessing that it would be safe enough to delete everything dated previous to the last bootup. Am I right?
Anne
It should actually be easier to go to runlevel 1 and remove everything in /tmp. It's very unlikely that there are any processes left that need /tmp in runlevel 1.
You should investigate, why you /tmp in filling up rapidly. Maybe this command helps to find the file/directory, that consumes most of the disk space:
du -sm * | sort -n
du -sm .??* | sort -n (for all hidden files and directories)
greets Boris
Hi, Boris. Thanks for the input. I was a bit worried, but it seems that I mis-read the logwatch file. It wasn't anywhere near full, though there were some old print jobs that needed cleaning out.
Anne
-
Anne Wilson -
Ed Greshko -
Fred Smith -
Joachim Backes -
magicus -
Michael A. Peters -
public＠boris-glawe.de -
Steve Searle