[Bug 57801] Tomcat catalina.sh fails to start after machine is reboot because there is another process have the same PID as Tomcat before reboot
https://bz.apache.org/bugzilla/show_bug.cgi?id=57801 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Mark Thomas --- This issue is as fixed as it is going to get. Using /tmp is the way to. The OS will set appropriate permissions so only root and the user Tomcat is running as can delete the file. -- 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
[Bug 57801] Tomcat catalina.sh fails to start after machine is reboot because there is another process have the same PID as Tomcat before reboot
https://bz.apache.org/bugzilla/show_bug.cgi?id=57801 --- Comment #8 from Konstantin Kolinko --- (In reply to Rainer Jung from comment #3) > Also added "ps" output for the process with the PID in r1672284 (trunk), > r1672285 (tc8) and r1672286 (tc7). Backported to Tomcat 6 in r1678326 and will be in 6.0.44 onwards. -- 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
[Bug 57801] Tomcat catalina.sh fails to start after machine is reboot because there is another process have the same PID as Tomcat before reboot
https://bz.apache.org/bugzilla/show_bug.cgi?id=57801
--- Comment #7 from jia...@gmail.com ---
Thanks Rainer and Christopher
It's not worth to set up a ramdisk to store the PID file.
If the PID file is stored in /tmp, the PID file may be rm-ed by someone.
The script should work in worst case even it's rare. The script should not
depend on the last state, it should be stateless.
The key point is catalina.sh treat the wrong process to be tomcat process.
Do we really need PID file to save the PID?
If we have issues with cross platform to verify the home path, maybe we could
first get the home path of the tomcat and then use this path to grep the right
PID in the result of ps(assuming the key commands in the following functions
exist in multiple unix/linux like OS).
Maybe we could get the PID of tomcat by some function like the following?
function get_tomcat_pid()
{
declare NORMALIZED=$(echo $CATALINA_HOME | tr -s / /)
declare NORMALIZED_PATH=$(readlink -f $CATALINA_HOME)
if [ "$NORMALIZED" != "$NORMALIZED_PATH" ]; then
NORMALIZED=$NORMALIZED_PATH
fi
if [ -z "$NORMALIZED" -a "${NORMALIZED+x}" = "x" ] ; then
return 1
fi
declare pid=`ps -ef | grep $NORMALIZED | grep -v grep | awk '{print $2}'`
if [ -z "$pid" -a "${pid+x}" = "x" ] ; then
return 1
fi
echo $pid
}
Thanks for supporting the force start.
The "abort" cases such as can't remove or write the PID file should be abort,
it looks that it does't have permission. Maybe user use the wrong user to run
the process.
The "abort" cases such as "PID file found but no matching process was found.
Stop aborted." , "$CATALINA_PID was set but the specified file does not exist."
should be a warning.
--
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
[Bug 57801] Tomcat catalina.sh fails to start after machine is reboot because there is another process have the same PID as Tomcat before reboot
https://bz.apache.org/bugzilla/show_bug.cgi?id=57801 --- Comment #3 from Rainer Jung --- Also added "ps" output for the process with the PID in r1672284 (trunk), r1672285 (tc8) and r1672286 (tc7). -- 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
[Bug 57801] Tomcat catalina.sh fails to start after machine is reboot because there is another process have the same PID as Tomcat before reboot
https://bz.apache.org/bugzilla/show_bug.cgi?id=57801 Rainer Jung changed: What|Removed |Added Product|Tomcat 8|Tomcat 6 Component|Catalina|Catalina Version|8.0.21 |6.0.43 --- Comment #2 from Rainer Jung --- I added the message "If this process is not a Tomcat process, remove the PID file and try again." to the output. The name of the PID file is already being output earlier during the script run. Added to trunk in r1672272, tc 8 in r1672273 (will be part of 8.0.22), tc 7 in r1672274 (will be part of 7.0.62) and proposed for TC 6. -- 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
[Bug 57801] Tomcat catalina.sh fails to start after machine is reboot because there is another process have the same PID as Tomcat before reboot
https://bz.apache.org/bugzilla/show_bug.cgi?id=57801 Rainer Jung changed: What|Removed |Added Severity|normal |enhancement Hardware|PC |All --- Comment #1 from Rainer Jung --- Either you should integrate your Tomcat stop (and probably start) into your system shutdown/startup (rc scripts or whatever methodology your system uses) or you rely on doing it by hand. In the latter case, Tomcat does not get any info about the system shutdown and can not react on it. Trying to find out whether the found process after reboot actually is a Tomcat process or something else is not the task of the start script.Integrating it will be error prone and hard to maintain cross platform. If you start by hand and get the cited error, you need to check the other process (like you did) and if it is something else and Tomcat is not running, purge the old PID file. We could probably make the message "Existing PID file found during start. Tomcat appears to still be running with PID 3387. Start aborted." a bit better "Existing PID file found during start. Tomcat appears to still be running with PID 3387. Start aborted. If the process with PID 3387 is not a Tomcat process, remove the PID file NAME_OF_PID_FILE_HERE and try again." -- 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
