Introduction

On one of my machine, I had a troubles because of /tmp filesystem is becoming full. The machine did not crash, but was not working correctly.

After investigation, the df command confirms the filesystem full.

But by doing ls or du, both do not list a big culprit file(s).

Nevertheless a reboot of the machine solve the situation.

So the mystery was why this behavior ?

The culprit is a log file

You have to know that, as a standard behavior, OpenBSD remove file older than 7 days from /tmp.

You can see this in your /etc/daily file.

find  .... -type f -atime +7 -execdir rm -f -- {}

Unfortunately, I had a daemon writing to a log file located in /tmp.

In such situation, the rm command remove the file from the /tmp folder, but since the filedescriptor is still open, the entries to the file are still there.
The rm will take effect as soon as the daemon free the filedescriptor.

To prove this, by killing the daemon free the space in /tmp.

Free space can be made by removing files AND by killing process writing to those files.

Possible solutions

Not tested, but one of the possible solution would be to detect if the file has an open filedescriptor before removing it. Maybe fstat could be used for that.

In /etc/daily, instead of doing:

find -x . \
    \( -path './ssh-*' -o -path ./.X11-unix -o -path ./.ICE-unix \
    -o -path './tmux-*' \) \
    -prune -o -type f -atime +7 -execdir rm -f -- {} \; 2>/dev/null

We could do:

find -x . \
    \( -path './ssh-*' -o -path ./.X11-unix -o -path ./.ICE-unix \
    -o -path './tmux-*' \) \
    -prune -o -type f -atime +7 -print | while read FILE
do
    [ "$(fstat "$FILE" | wc -l)" == "1" ] && rm -f -- "$FILE"
done

To be tested ;-)