SpringBoot embedded Tomcat temporary directory problem and solution

SpringBoot embedded Tomcat temporary directory issue

I heard that the temporary tomcat folder may be deleted by Linux after going online, and an error will be reported. Now I will record it quickly, and it has been needed from time to time.

There is a SpringBoot project with file uploads. After the Linux system is deployed, a temporary directory with tomcat and random strings will be generated in the system's tmp directory.

This directory may be automatically cleared by the Linux system after a certain period of time, resulting in an error when uploading the file again.

It means that the temporary directory of tomcat will betmpwatchDelete, maybe even deleteclassFile, causing errors to occur

1. Background

Online guarantee, SpringBoot application that has been online for several days, suddenly encountered problems:

/tmp/tomcatXXX/work/Tomcat/localhost/XXX is not valid。

The application will not exist in the /tmp/tomcatXXX/work/Tomcat/localhost/ROOT directory. After query, when tomcat uploads the file, it will first copy the file to the temporary directory, that is, the directory.

The previous application was running normally, but now this situation occurs, it is obvious that the created directory has been deleted. Yes, this special /tmp directory has a clearing strategy for Linux.

The configuration file path to clear the policy is as follows:

/usr/lib//

Open

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# See (5) for details

# Clear tmp directories separately, to make them easier to override
v /tmp 1777 root root 10d          
v /var/tmp 1777 root root 30d      

# Exclude namespace mountpoints created with PrivateTmp=yes
x /tmp/systemd-private-%b-*
X /tmp/systemd-private-%b-*/tmp
x /var/tmp/systemd-private-%b-*
X /var/tmp/systemd-private-%b-*/tmp

It is found that files that have not been accessed within 10 days will be cleared. But here, there is a question: what is OK yesterday is that the directory was accessed, so how could it be cleared today?

I was really confused at the time, and then my assumption about the application was:

/tmp/tomcat.4344543554352.8080/work/Tomcat/localhost/test, it is found that the directory is empty. That is, temporary files will be cleaned up by tomcat, but the creation time of the test directory was indeed 10 days ago.

I understand here that although the files in the test directory are updated every day, ** will not affect the access time of the test directory**, and the file has been deleted. The /tmp directory cleaning mechanism found that the empty directory of test was 10 days ago, so it was cleaned up directly (**test is an empty directory**). If you go to the application again, you will report an error.

2. Plan

Once the reasons are clear, the solution is naturally clear, there are roughly 3 types:

• 1. Modify the /tmp directory cleaning strategy from the Linux level. It is relatively simple, skip it
• 2. Specify the new system temporary file path

-=/var/tmp

• 3. Modify the temporary directory of tomcat in the configuration

server:
    tomcat:
       basedir: /var/tmp/

3. Configure the tomcat temporary directory in the code

@Configuration
public class MultipartConfig {
@Bean
MultipartConfigElement multipartConfigElement() {
MultipartConfigFactory factory = new MultipartConfigFactory();
String location = ("") + "/data/tmp";
File tmpFile = new File(location);
if (!()) {
();
}
(location);
return ();
}
}

Created first if the temporary directory does not exist

This plan is a little more troublesome, so talk more about it.

In fact, this method has been revised in spring-boot 2.1.4 version: if the temporary directory does not exist, it will create a temporary directory.

Several lines of code were added to this class spring-boot/src/main/java/org/springframework/boot/context/embedded/tomcat/:

        catch (NoSuchMethodError ex) {
            // Tomcat is < 8.0.30. Continue
        }
        //Add new code starts        try {
            (true);
        }
        catch (NoSuchMethodError ex) {
            // Tomcat is < 8.5.39. Continue.
        }
         //The new code ends         (context, );

Summarize

The above is personal experience. I hope you can give you a reference and I hope you can support me more.