https://bz.apache.org/bugzilla/show_bug.cgi?id=64485
Bug ID: 64485
Summary: UserDatabase Realm leaks os file descriptors for
conf/tomcat-users.xml
Product: Tomcat 9
Version: 9.0.35
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: -----
Created attachment 37285
--> https://bz.apache.org/bugzilla/attachment.cgi?id=37285&action=edit
Stacktrace of file open failure when os file descriptors is over (recorded with
v9.0.29)
There is a bug in org.apache.catalina.users.MemoryUserDatabase that leaves the
os file descriptors in open state.
This is caused by the code line:
https://github.com/apache/tomcat/blob/9.0.35/java/org/apache/catalina/users/MemoryUserDatabase.java#L428
Exact code line is:
this.lastModified =
resource.getURI().toURL().openConnection().getLastModified();
The org.apache.tomcat.util.file.ConfigurationSource.Resource is handled
properly by the try-with-resources block, but a call to the URI/URL inside this
block does not close any opened resources.
These resources just stay in memory and occupy limited os resources.
There is a similar bug in the OpenJDK:
https://bugs.openjdk.java.net/browse/JDK-6956385
This behavior was introduced in version 9.0.13 and after bugs:
https://bz.apache.org/bugzilla/show_bug.cgi?id=62924
https://bz.apache.org/bugzilla/show_bug.cgi?id=62958
The leaked file handles are usually collected by the GC, but if server has
enough memory and stays idle, then too many handles are acquired from the os
and there is no more available.
A stacktrace of such failure is in the attachment.
The read time period is 10 seconds by default and one file handle is leaked
withing every read of tomcat-users.xml file.
MemoryUserDatabase#watchSource is also true by default and this behavior is
enabled in the default conf.
A list of open files can be obtained by cmd:
lsof -K | grep $TOMCAT_PID | grep "tomcat-users.xml" | wc -l
org.apache.tomcat.util.file.ConfigurationSource.Resource#getLastModified() may
be voulnerable too.
Please analyze all places where java.net.URL#openConnection() is used
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
