On 12/20/2017 10:05 AM, Matthew Roth wrote: > I am building a few suggester's and I am receiving the error that I have no > space left on device.
<snip> > At first this threw me. df showed I had over 100 G free. the /data dir the > suggester is being constructed from is only 4G. On a subsequent run I > notice that the suggester is first being built in /tmp. When setting up the > LVM I only allotted 2g's to that directory and I prefer to keep it that > way. The code is utilizing the "java.io.tmpdir" system property to determine a temporary directory location to use for the build, before it is put in the final location. On POSIX platforms, this will default to /tmp. If you are starting Solr manually, then you would just need to add the following parameter to the bin/solr commandline (including the quotes) to change this location: -a "-Djava.io.tmpdir=/other/tmp/path" If you've installed Solr as a service, then I do not think there's any easy way to adjust this property, other than manually editing bin/solr to add the -D option to the startup commandline. We'll need an enhancement issue in Jira to modify the script so it can set java.io.tmpdir from an environment variable. Note that adjusting this property may result in other things that Solr creates being moved away from /tmp. Since most POSIX operating systems will automatically delete old files in /tmp, it's always possible that when you move Java's temp directory, you'll end up with cruft in the new location that never gets deleted. Developers do generally try to clean up temporary files, but sometimes things go wrong that weren't anticipated. If that does happen and a temporary file is created by Lucene/Solr that doesn't get deleted, then I would consider that a bug that should be fixed. On Windows systems, Java asks the OS where the temp directory is. The info I've found says that the TMP environment variable will override this location for Windows, but not for other platforms. Thanks, Shawn
