I noticed that I currently have 34736 .tmp files in GEOSERVER_ROOT/data directory along with the usual files and directories. From what it seems, these files are copies of the global.xml file, as their names are:


The only difference between these files and the original global.xml is the value of updateSequence, which increases by one with every new file created:


.tmp files:

The value from the last created file corresponds to the value listed on Server Status in GeoServer GUI:

Update Sequence 210867

From GeoServer User Manual:

"Update Sequence Refers to the number of times (60) the server configuration has been modified."

Possible explanation: I have an automated script that fetches some files from a FTP, processes them and uploads them to Geoserver via curl. The script runs every hour.

So the configuration is being modified, but shouldn't the global.xml file be updated?

I could create a .bat file that deletes them once in a while, but I would like to find out why they are created in the first place.

So my question is:

Why does GeoServer create these temp files (and forgets to delete them) and doesn't update the original global.xml?

- EDIT -

I tried to take it step by step to see what happens. Apparently, if I create a new workspace and I upload a file in the newly created coverageStore, it works without any errors and no global.xml.tmp files.

But if I do that for all the files from a folder..

import urllib
import urllib2
import base64

base64string = base64.encodestring('%s:%s' % ("x", "x"))[:-1]
authorizationHeader =  "Basic %s" % base64string;

baseURL = "http://x:x/geoserver/rest/"

headers1 = { "Content-type" : "application/xml", "Authorization": authorizationHeader}
coverageBaseURL = baseURL + "workspaces/Radar/coveragestores?configure=all"

headers2 = { "Content-type" : "image/tiff", "Authorization": authorizationHeader}
uploadBaseURL = baseURL + "workspaces/Radar/coveragestores/"

for file in os.listdir(resultPath):
if file.endswith(".tif"):
    name = os.path.splitext(file)[0].split("_")[4]

    #Create coverageStores for each file in GeoServer
    data1 = '<coverageStore><name>' + name + '</name><workspace>Radar</workspace><enabled>true</enabled><type>GeoTIFF</type><url>/radar/</url></coverageStore>'
    req1 = urllib2.Request(coverageBaseURL, data1, headers1)    
    response1 = urllib2.urlopen(req1)
    the_page1 = response1.read()

    #Upload files to GeoServer
    url2 = uploadBaseURL + name + "/file.geotiff"
    data2 = open(file, 'rb').read()
    req2 = urllib2.Request(url2, data2, headers2)
    req2.get_method = lambda: 'PUT'
    response2 = urllib2.urlopen(req2)
    the_page2 = response2.read()

.. I get the following error in GeoServer's log:

04 Nov 14:06:02 ERROR [config.impl] - Error occurred processing a configuration
change listener
org.geoserver.catalog.CatalogException: Error persisting GeoServerInfoImpl[null]
 to global.xml
Caused by: java.io.IOException: Failed to move %GEOSERVER%\data\global.xml.3a26dbde-4e4f-4f35-8fba-be3f81e2debb.tmp -
unable to remove existing: %GEOSERVER%\data\global.xml

So the error must be related to the loop, somehow.

  • You say that GeoServer creates thousands of such files. Do you have thousands of updates and one tmp file per update, or does GeoServer go mad and create thousands of tmp files after you have done just one update?
    – user30184
    Nov 2 '16 at 14:46
  • @user30184 I have added details to my post.
    – Ralu Bur
    Nov 2 '16 at 15:30
  • 1
    I would say that you should do some research 1) Send the REST request to delete Radar workspase - did there appear new .tmp files? 2) Create Radar workspace... 3) upload 54 tiff files to workspace - how many .tmp files did you get 4) change style and see what happens. Compare a few of the operations with doing them manually through the web UI. Report your findings.
    – user30184
    Nov 2 '16 at 15:36
  • 1
    GeoServer creates a tmp file each time it's rewriting a config file, and then removes the original file and renames the tmp one, to avoid having a partially written file at any time. Wondering if that action is somehow cut in half by some other issue... possible scenario, you're on Windows, the file is read locked by something else, and GeoServer fails to complete the rename... I would expect plenty of errors in the logs about that, and possibly a 500 return code from the REST call? Nov 3 '16 at 8:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.