https://bz.apache.org/bugzilla/show_bug.cgi?id=65970
--- Comment #3 from eddie...@sap.com --- (In reply to Christopher Schultz from comment #1) > This situation was probably caused by a very unusual circumstance, such as a > power failure or kill-9 signal. > > It's not clear what you are asking for, here. If CATALINA_PID exists and > there is an existing process matching that PID, then Tomcat will not start > because it looks like Tomcat is already running. > > With a low PID like that, it's probably a process that runs on startup, and, > with a stale PID file it's very likely to match another process that was > started on startup as well. > > A better solution for you might be to place your PID file on volatile > storage, or somewhere the OS will clear-out upon reboot, like /tmp. Not all > OSs clear-out /tmp on reboot, but some of them do. Another option would be > to instruct your init system to delete certain files (including the Tomcat > PID file) early-on in the boot process to make sure the PID file just > doesn't exist at all. thanks for your reply. I am aware of the work around (or solution), that is to use /run to store file $CATALINA_PID just want to clarify why I think there is a potential enhancement here. exactly I am talking about the case of power failure or kill-9 signal. basically in such scenario, current scrip code will treat the stale PID (which is generated before VM reboot) as current running tomcat process and hence refuse to start Tomcat. My expectation is that Tomcat script to ignore this stale PID and go ahead to startup. And I propose to compare the time stamp of $CATALINA_PID file and the time when reboot happened to judge whether it is a STALE PID. >From my perspective, if we enhance it like this, then we need not resort to volatile storage like /run. and End user even will not notice such details. Or put it in another way, solution/enhancement from Tomcat is much better than the solution/work around outside of Tomcat. Thanks again for your understanding of my end user perspective. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
