On 11/11/2014 16:47, Gary Gregory wrote: > Sorry, I meant what version of Commons Daemon.
It is the latest release. 1.0.15. Mark > > Gary > > On Tue, Nov 11, 2014 at 11:37 AM, Anil Ambati <[email protected]> wrote: > >> I am using Apache Tomcat 7.0.56. I think that is the latest. >> >> Regards, >> ------------------------------ >> *Anilkumar Ambati* 4205 S Miami Blvd >> WebSphere Virtual Enterprise Development Durham, 27703-9141 Phone: >> +1-919-254-6152 USA Mobile: +1-919-434-5674 e-mail: [email protected] >> >> ------------------------------ >> "You have no responsibility to live up to what other people think you >> ought to accomplish." -Richard Feynman (1918-1988) >> >> >> >> From: Gary Gregory <[email protected]> To: Commons Users List < >> [email protected]>, Date: 11/11/2014 10:18 AM Subject: Re: >> [daemon] Unable to read tomcat.pid file created by Tomcat process >> ------------------------------ >> >> >> >> So which version of [daemon] are you using? Can you try the latest and >> greatest. It might not matter but it'll make debugging easier for anyone on >> this ML. >> >> Gary >> >> On Tue, Nov 11, 2014 at 10:06 AM, Anil Ambati <[email protected]> wrote: >> >>> I was asked to post this question in this forum. >>> >>> We have a requirement to read the PID file created by the Tomcat server >>> process on Windows, but we are not able to using RandomAccessFile or >>> FileInputStream because the file seems to be >>> locked by the Tomcat process. >>> >>> Why does the Tomcat server keep the PID file locked, preventing other >>> processes to even read the file? Is there a work around or solution for >>> this problem? >>> >>> >>> Christopher Schultz wrote this in Tomcat user forum: >>> ---------------------------------------------------- >>> I took a quick look, and it looks like the PID file is being created >>> with a file option FILE_FLAG_DELETE_ON_CLOSE which causes the OS to >>> delete the file off the disk when all file handles are closed. So, >>> closing the file handle will result in the PID file being deleted. >>> >>> This option was added because the PID file wasn't being removed if the >>> service crashed, which kept the service from restarting (oops). >>> >>> https://issues.apache.org/jira/browse/DAEMON-183 >>> >>> It seems like an option to control what happens on startup when the >>> PID file already exists would be a good idea. You'll have to ask the >>> procrun folks about what the options are. It seems reasonable to be >>> able to read the PID file, since not being able to read it makes it >>> kind of useless other than as a lock-file (i.e. its contents are >>> irrelevant). >>> >>> >>> Regards, >>> ------------------------------ >>> *Anilkumar Ambati* 4205 S Miami Blvd >>> WebSphere Virtual Enterprise Development Durham, 27703-9141 Phone: >>> +1-919-254-6152 USA Mobile: +1-919-434-5674 e-mail: >> [email protected] >>> >>> ------------------------------ >>> "You have no responsibility to live up to what other people think you >>> ought to accomplish." -Richard Feynman (1918-1988) >>> >> >> >> >> -- >> E-Mail: [email protected] | [email protected] >> Java Persistence with Hibernate, Second Edition >> <http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
