Mark and Chris, Thank you again for your replies. Responses inline below.
TLDR; I have answers and comments below, but I feel this has taken up a fair amount of your time. If you wish to dig further into this, I'd certainly like to understand what (at least may have) happened. If not, I don't think this is very likely to have been a security incident, and I suppose I'll just chalk it up to being related to the disk being full. thanks, - Linus On Thu, Dec 11, 2025 at 1:09 PM Christopher Schultz < [email protected]> wrote: > Mark and Linus, > > On 12/11/25 2:28 AM, Mark Thomas wrote: > > On 10/12/2025 21:58, Linus Kamb wrote: > >> Mark, > >> > >> Thanks very much for your response. > >> > >> The disk is local, not shared. > > > > So given the statement "... the disk from which all the tomcats run ..." > > does this mean we are talking about multiple Tomcat instances running on > > a single physical machine? Or something else? > Yes. All tomcats are running on one physical machine. The tomcat instances are all separate, complete installs with their own webapps directories, and each distinct webapp has its own data directory on a separate local (logical - /dev/mapper ) disk. > > > Are any files shared between the instances? > There should not be. > > > How is the web application deployed? WAR file that Tomcat then expands? > Yes. autoDeploy had been turned on. We are turning that off. > > > > I want to make sure I understand the architecture before I spend too > > much time thinking about what might be going on. > Understandably. And I don't want to take too much of your time. > > > >> Could the fact that there was no space left on the disk be treated as > >> being unavailable? > > > > Seems unlikely. Tomcat has a list of files it checks for each webapp and > > looks to see if the modification time has changed. > Is there a list of those files? > > > >> And why only the one webapp? Perhaps because it was the one Full disclosure, in case it makes a difference: I missed one of the tomcats -- it did not have the one particular webapp. In that tomcat, *all* of its webapps were redeployed. However, there was a tomcat with the main webapp that had one additional webapp. That additional webapp was *not* redeployed. FWIW. > >> attempting to > >> write to the disk? > > > > Again, seems unlikely. > > > > Might some external process changed the last modification time on any > > files? A back-up process maybe? Those times should not be sensitive to > > clock / time zone changes but I'd check if there were any changes of > > that nature just in case. > > I am not aware of any external process that would touch files in the webapp directories. Looking at the webapp directories now, nothing has changed since redeployment. All the webapps were undeployed (as noted in the logs) and then redeployed, presumably unpacking the war. The webapp deployment directory was restored to its state as in the war. The timestamps on all the files in the deployment directory are equal to their timestamps in the war, but all the directories had timestamps ~equal to the time of redeployment. Unfortunately, since the webapps were all undeployed, I cannot evaluate the contents and file timestamps prior to undeployment. (I am assuming that when the logs say "Undeploying context," that means it removes the webapp directory. Either way, everything was restored as if unpacked from the war.) +1 > > Is the web application configured to auto-reload? Tomcat will watch more > than just the timestamp on the application's deployment directory for > changes. There are other files that can cause a reload. (But generally > not a re-deployment.) > > I don't believe the application or server were configured to auto-reload. I find no mention of reloadable. The logs (that were able to be written) stated "Undeploying <webapp> context." (Or maybe context <webapp>) And followed later by indicating the redeployent of the webapp. -chris > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
