When /tmp fills up

When /tmp fills up, apps lose a place to write short-lived files, so MySQL sorts, package installs, and even some service starts can fail with odd errors. You often see messages about temporary files, a panel update that will not finish, or a site that suddenly cannot create sessions. Start with df /tmp so you know whether that path is actually full, then find what is writing there. Do not chmod 777 /tmp to “fix” it; the correct mode is sticky 1777 so users can write but only remove their own files.

Remember that “tmp” is not always one folder. You may have the root filesystem’s /tmp, a separate tmpfs mount, or a service using systemd PrivateTmp= so its /tmp is private. PHP may use sys_temp_dir and MySQL may use tmpdir if those were pointed elsewhere. A check of / can look fine while a small tmpfs on /tmp is already at 100%.

df -h /tmp; du -xh /tmp | sort -h | tail

df -h /tmp shows which filesystem that path sits on and how full it is. du lists the visible files so you can remove or rotate the large ones. If du looks small while df says full, you may have deleted files still held open by a process, or PrivateTmp hiding usage in another namespace. lsof +D /tmp is slow and noisy, so use it when df and du disagree and you need the holding process.

How applications use /tmp

MySQL can leave sort leftovers such as #sql files, and a stale socket in a full /tmp can stop a new mysqld from starting cleanly. Free space first, start the database, then point tmpdir at a disk with room if your sorts are large. On some systems APT unpacks under /tmp, so a full tmp can look like a broken mirror when the real issue is free space. PHP session files and forgotten debug dumps are common fillers on shared and VPS hosts as well.

systemd PrivateTmp

If a unit has PrivateTmp=yes, it does not write into the /tmp you are browsing in a normal shell. Those files live under paths like /tmp/systemd-private-* or only inside that service’s namespace. Check the unit’s private tmp, not only a plain ls /tmp. PHP-FPM and MariaDB units often enable this, which is why the disk can look empty from outside while the service still fails.

Clear space without making it worse

/tmp is scratch space, and when it fills you get an outage until something gives. Find the writer, remove or rotate what you can safely drop, and cap whatever keeps filling it. Avoid a reboot just to clear tmp unless you already know the problem is deleted-but-open files and you know which process holds them. On a LogicWeb VPS you have root and can fix mounts and services yourself; on shared hosting there is no root, so open a ticket if you cannot clear the path from your account tools.