$JENKINS_HOME directory contains seemingly random temporary files named
atomic3388423418863564689tmp. For example:
$ ls -ltr total 858152 -rw-r--r-- 1 jenkins jenkins 2231 Jun 27 06:30 atomic3388423418863564689tmp -rw-r--r-- 1 jenkins jenkins 4821472 Jul 9 06:01 atomic4091643413878123751tmp -rw-r--r-- 1 jenkins jenkins 3974602 Jul 10 06:30 atomic3994643465400727330tmp -rw-r--r-- 1 jenkins jenkins 7773238 Jul 11 06:00 atomic4080609592580645206tmp -rw-r--r-- 1 jenkins jenkins 2189403 Jul 17 06:30 atomic5955839104358656441tmp -rw-r--r-- 1 jenkins jenkins 14269927 Jul 18 06:00 atomic5324885293281305058tmp ...
In some cases, these files can be consuming a non-trivial amount of disk space. What are these files and can they safely be deleted?
When modifying configuration files, Jenkins uses an atomic file writer. This means changes are first written to a temporary file before being committed to the target file. There are several situations that could cause these files to get left behind. For example, if Jenkins home directory is mounted on an NFS, a transient network condition may have prevented Jenkins from completing I/O on those files. Another possibility is that Jenkins was forcibly terminated, thereby preventing the completion of pending I/O operations.
The atomic file writer is used by Jenkins core and many plugins. Hence the file in question could be written by either Jenkins Core or any plugin. If you are curious, you can try to determine which plugin created these files using the unix
head <filename> command to peek at the file contents.
You should check the last modified timestamp to see whether the files have been accessed recently. If not, the files can be safely deleted. After deleting the files, monitor your Jenkins instance to see whether they get re-created. If so, there may be an I/O issue on the machine hosting Jenkins. Please collected the data described here: Required Data: IO issues on Linux, along with a sample of the atomic files (preferably compressed).