Hello world!
Yesterday I installed Linux Mint Debian Edition (LMDE) on my notebook. It seems to be a rock solid distribution, but as Clem announced in his blog post it has “some rough edges”. One rough edge I had been experiencing was an annoying “no space left on device” error when I tried to install Oracle JDeveloper on my brand new system. Believe it or not: The error cause is not a bug – it is a feature! This post is about fixing the installation issue caused by that feature. Although it talks about a JDeveloper installation the suggested ways can be a applied to other programs that cause the issue mentioned above.
Scenario
As described in the previous paragraph I tried to install Oracle JDeveloper 11.1.1.6.0 on my notebook:
|
1 |
java -jar jdevstudio11116install.jar |
After a few seconds the following window was popping up:
Cause Analysis
The error description “no space left on device” was a little bit confusing to me, because I just installed LMDE on a 500 GiB hard disk and I could not imagine that LMDE would have occupied the whole disk space. When checking the free disk space with
|
1 |
df -k |
I recognized the high usage of the /tmp partition (96%, line 6):
|
1 2 3 4 5 6 7 |
Filesystem 1K-blocks Used Available Use% Mounted on rootfs 477387180 15714056 437778136 4% / udev 4032380 0 4032380 0% /dev tmpfs 807556 912 806644 1% /var/run tmpfs 5120 0 5120 0% /var/run/lock tmpfs 1615112 1541124 73988 96% /tmp tmpfs 1615112 76 1615036 1% /var/run/shm |
Newer debian (linux) systems allow to use RAM as a “directory” for writing / reading temporary data. This increases speed of programs that need space for temporary data. For the most use cases the size of such a RAM-based temporary partition is adequate. An insurgent program that needs a huge amount of temporary space is the Oracle JDeveloper installer. It looks up the system’s temp directory in order to extract round about 2 GiB of data to that directory. So the cause of the occuring “no space left on device” error was the huge amount of data the installer tried to write to my limited RAM-based /tmp partition.
Solutions
There are (at least) three ways to solve the issue.
Solution 1 – Dynamically resize /tmp at runtime
Because /tmp is mounted as a tmpfs you can resize it dynamically at runtime. Just clear the content of /tmp and resize its space:
|
1 2 3 |
sudo rm -rf /tmp/* sudo mount -o remount,size=2560m /tmp java -jar jdevstudio11116install.jar |
This is the recommended way, because it ensures a fast running installation process. For installing JDeveloper the size of 2560m (= 2.5 GiB) was adequate. Depending on your use case you might have to choose a higher value like 3g (= 3 GiB).
Solution 2 – Use custom directory instead of RAM for temporary data (java specific)
The JDeveloper installer is a java program. So it is possible to configure a custom temp directory via _JAVA_OPTIONS environment variable:
|
1 2 3 |
mkdir $HOME/tmp export _JAVA_OPTIONS="-Djava.io.tmpdir=$HOME/tmp $_JAVA_OPTIONS" java -jar jdevstudio11116install.jar |
Runtime of this approach is a little bit slower than runtime of solution 1, but it works…
Solution 3 – Use disk space instead of RAM (system-wide and permanent => slows down programs that access /tmp)
Another solution is to prevent /tmp from being mounted as RAM based tmpfs. To achieve this perform the following two simple steps and you are done:
- Edit /etc/default/rcS as superuser and replace RAMTMP=yes by RAMTMP=no
- reboot
Works like solution 2, but is not java specific. In contrast to the first two solutions, it has a permanent effect. You should choose this option, if you are constantly experiencing the “no space left on device” error when running various programs.
Please note: A filled to overflowing /tmp partition is not the only matter that can cause a no “space left on device” error. If you are not able to identify a chock-full /tmp partition by using
|
1 |
df -k |
try
|
1 |
df -i |
to see, if you are running out of inodes. If you are able to identify a value near 100% follow the instructions on Ivan Kuznetsov’s blog.