TIL: Insufficient /tmp Space Causes GBase Database Installation Failure

Today I ran into a common but easy-to-miss GBase Database(GBase 8s) installation problem. The installer stopped with No space left on device, even though the target disk still had tens of gigabytes available. The real bottleneck was not /opt or the main disk—it was the /tmp filesystem used during installation.

The Symptoms

During a GBase Database installation:

./ids_install

the installer suddenly terminated with an error similar to:

ERROR: Failed to extract files. Disk may be full.

I checked the main installation filesystem:

df -h /opt

and found plenty of free space.

The confusing part was that the GBase 8s installation still reported that the disk was full.

The Root Cause: Check /tmp

The GBase Database(GBase 8s) installer may use /tmp for temporary extraction and installation files. Therefore, having enough free space on the target installation directory does not necessarily mean that the installer has enough temporary storage.

The first checks should be:

df -h /tmp
du -sh /tmp/ids_install* 2>/dev/null

Also check the filesystem behind /tmp:

df -h /tmp
df -i /tmp

The second command is important because No space left on device can also occur when a filesystem runs out of inodes, even when df -h still shows available capacity.

Solution 1: Clean Up Temporary Files

If /tmp is genuinely full, identify large files first:

du -sh /tmp/* 2>/dev/null | sort -rh | head -20

Remove only files that you have verified are safe to delete.

For example:

find /tmp -name "ids_install*" -mtime +1 -delete

Avoid blindly deleting everything under /tmp, especially on a production server where other applications may be using temporary files.

Solution 2: Provide a Larger Temporary Directory

For a GBase Database installation that requires more temporary space, using a dedicated filesystem or directory can be a cleaner approach.

For example:

mkdir -p /opt/tmp
chmod 1777 /opt/tmp

export TMPDIR=/opt/tmp

./ids_install -i console

Before starting the installation, verify that the new location has sufficient capacity:

df -h /opt/tmp
echo $TMPDIR

Using a dedicated temporary directory also makes it easier to monitor installation-related files during troubleshooting.

Solution 3: Increase the Available Space for /tmp

If /tmp is backed by a small filesystem or tmpfs, increasing its capacity may be appropriate depending on your server configuration.

First inspect the current setup:

df -h /tmp
mount | grep ' /tmp '

Then resize or reconfigure /tmp according to your operating system and deployment standards.

I would not recommend blindly running a new mount -t tmpfs ... /tmp on a production system. Changing the /tmp mount can affect existing processes and may require additional configuration to survive a reboot.

Pre-Installation Check for GBase Database

A simple pre-check can catch many installation problems before running the GBase 8s installer:

#!/bin/bash

echo "=== Disk Space Check ==="
echo "/tmp: $(df -h /tmp | tail -1 | awk '{print $4}') available"
echo "/opt: $(df -h /opt | tail -1 | awk '{print $4}') available"
echo "HOME: $(df -h ~ | tail -1 | awk '{print $4}') available"

echo ""
echo "=== Inode Check ==="
df -i /tmp

echo ""
echo "=== Memory Check ==="
free -h

echo ""
echo "=== Dependency Package Check ==="
for pkg in unzip libaio libgcc libstdc++ ncurses-devel; do
    rpm -q "$pkg" &>/dev/null \
        && echo "[OK] $pkg" \
        || echo "[MISSING] $pkg"
done

Why This Matters in Batch Deployments

This problem becomes more noticeable when deploying GBase Database(GBase 8s) across multiple servers.

A machine may have plenty of capacity on /opt, while /tmp has a much smaller limit. During simultaneous installations, temporary extraction files can consume that space quickly.

A successful GBase Database installation therefore requires more than checking the final installation directory. You should verify temporary storage, filesystem capacity, inode availability, memory, and required packages before starting the installer.