In a true case of irony, I tried to "find"
if there was anything I owned, and not remembering the command details
tried "man find" and got
$ man find
Man: find all matching manual pages
* find (1)
Man: What manual page do you want?
/usr/bin/nroff: Can't create temp directory,
Luckily, I could read the syntax on
another machine ... and what I was looking for was
find /tmp -user wtpBuild 2>/dev/null
But, I didn't have enough there to make
I suggest any 'release engineers' with
shell accounts try to clean up any big stuff this weekend, in case webmasters
don't see this thread till Monday ... but I can't really "see"
who/what might be using a lot of space. (I think "emf search"
has been a contributor in the past .... but, I'm not pointing fingers since
I have no idea ... and I am sure it's a combination of issues).
But to answer your last question, there's
all kinds of stuff that end up on /tmp. Most of it is tiny. Much of it
put there by "system stuff". Currently /tmp is set at 5 Gigs
(i.e. not huge, not meant to "store stuff"), and I think the
webmasters have a cron job that cleans up anything over 14 days old ...
but, not fool proof to keep it clear, obviously.
One common source of "big stuff"
that can build up there is if projects run unit tests and use Java's createTempDir
API to create a temporary directory, say for test workspaces, or something.
By default, it uses /tmp but can be overriden if your java invocation sets
it to another directory using java.io.tmpdir
system property. I know we in webtools set that system property to some
of our own space on "shared" because for a while (years ago)
we were filling up /tmp on a few occasions. So, now we set to our own "space"
and can make sure it gets cleaned up on a more regular basis.
Stephan Herrmann <stephan@xxxxxxxxxxxxxxx>
Cross project issues
05/21/2011 11:49 AM
build.eclipse.org/tmp is full
builds on build.eclipse.org currently fail with
java.io.IOException: No space left on device
I can't really see, wich file is affected, as this comes somewhere from
within p2, but df shows that only one partition is short in space:
/tmp is 100% used.
Sounds like a good opportunity for some folks to do some cleanup, no?
I mean, who would leave large amounts of data on /tmp anyway?