|Summary:||catalina.sh fix in #49728 breaks PID handling again|
|Product:||Tomcat 6||Reporter:||Robert Oschwald <roos>|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
|Attachments:||Patch to fix existing, empty pid file handling|
Description Robert Oschwald 2010-10-13 08:06:57 UTC
The pid handling fix in #49728 breaks PID handling again. The fix now removes empty PID files before start. This doesn't work on RHEL5/CentOS5 (and maybe others), where tomcat is started as non-root user. The pid files on these OS's are in /var/run, which is only writeable by root. Therefore, the init.d script creates the pid file and sets the permissions accordinghly. This is not working anymore, as catalina.sh tries to remove this empty file and skips filling the file as it cant remove it.
Comment 1 Konstantin Kolinko 2010-10-13 08:42:26 UTC
What is your suggestion how to deal with it? I might think about truncating the stale PID file instead of deleting it. To truncate a file one might redirect empty output to it, as shown in , using the "colon" (no-op) command: :>"$CATALINA_PID"  http://linuxdemon.blogspot.com/2007/06/how-to-truncate-file-in-unixlinux.html The following also works: true>"$CATALINA_PID"
Comment 2 Robert Oschwald 2010-10-13 08:48:16 UTC
In my opinion, thats not necessary. I will add a patch to this ticket with my workaround to the problem. Basically, when an empty pid file exists, its' just filled by catalina.sh
Comment 3 Robert Oschwald 2010-10-13 08:56:37 UTC
Created attachment 26167 [details] Patch to fix existing, empty pid file handling Note: echo $! > "$CATALINA_PID" creates the file if not existent and fills existing files (overwrites existing content)
Comment 4 Mark Thomas 2010-10-19 10:55:58 UTC
Thanks for the report and the suggested patch. I applied a different patch that retained the current behavior where the containing dir is writable but better handles (without error messages) the case where it is not. Fixed for 7.0.x and will be included in 7.0.5 onwards. Proposed for 6.0.x.
Comment 5 Mark Thomas 2010-10-21 07:58:33 UTC
*** Bug 50130 has been marked as a duplicate of this bug. ***
Comment 6 Mark Thomas 2010-10-26 12:15:36 UTC
Fixed in trunk and will be in 6.0.30 onwards.