Discussion:
[daemon] Unable to read tomcat.pid file created by Tomcat process
Anil Ambati
2014-11-11 15:06:48 UTC
Permalink
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:
***@us.ibm.com


"You have no responsibility to live up to what other people think you
ought to accomplish." -Richard Feynman (1918-1988)
Gary Gregory
2014-11-11 15:12:09 UTC
Permalink
Oops, sorry, please ignore my previous message.
Wrong list. You probably want
https://tomcat.apache.org/lists.html#tomcat-users
Gary
Post by Anil Ambati
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?
----------------------------------------------------
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
------------------------------
"You have no responsibility to live up to what other people think you
ought to accomplish." -Richard Feynman (1918-1988)
--
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
--
E-Mail: ***@gmail.com | ***@apache.org
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
Gary Gregory
2014-11-11 15:14:13 UTC
Permalink
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
Post by Anil Ambati
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?
----------------------------------------------------
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
------------------------------
"You have no responsibility to live up to what other people think you
ought to accomplish." -Richard Feynman (1918-1988)
--
E-Mail: ***@gmail.com | ***@apache.org
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
Anil Ambati
2014-11-11 16:37:13 UTC
Permalink
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:
***@us.ibm.com


"You have no responsibility to live up to what other people think you
ought to accomplish." -Richard Feynman (1918-1988)






From:
Gary Gregory <***@gmail.com>
To:
Commons Users List <***@commons.apache.org>,
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
Post by Anil Ambati
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?
----------------------------------------------------
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
------------------------------
"You have no responsibility to live up to what other people think you
ought to accomplish." -Richard Feynman (1918-1988)
--
E-Mail: ***@gmail.com | ***@apache.org
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
Gary Gregory
2014-11-11 16:47:19 UTC
Permalink
Sorry, I meant what version of Commons Daemon.

Gary
Post by Anil Ambati
I am using Apache Tomcat 7.0.56. I think that is the latest.
Regards,
------------------------------
*Anilkumar Ambati* 4205 S Miami Blvd
------------------------------
"You have no responsibility to live up to what other people think you
ought to accomplish." -Richard Feynman (1918-1988)
[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
Post by Anil Ambati
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?
----------------------------------------------------
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
------------------------------
"You have no responsibility to live up to what other people think you
ought to accomplish." -Richard Feynman (1918-1988)
--
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
--
E-Mail: ***@gmail.com | ***@apache.org
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
Mark Thomas
2014-11-11 16:50:11 UTC
Permalink
Post by Gary Gregory
Sorry, I meant what version of Commons Daemon.
It is the latest release. 1.0.15.

Mark
Post by Gary Gregory
Gary
Post by Anil Ambati
I am using Apache Tomcat 7.0.56. I think that is the latest.
Regards,
------------------------------
*Anilkumar Ambati* 4205 S Miami Blvd
------------------------------
"You have no responsibility to live up to what other people think you
ought to accomplish." -Richard Feynman (1918-1988)
[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
Post by Anil Ambati
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?
----------------------------------------------------
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
------------------------------
"You have no responsibility to live up to what other people think you
ought to accomplish." -Richard Feynman (1918-1988)
--
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: user-***@commons.apache.org
For additional commands, e-mail: user-***@commons.apache.org
Anil Ambati
2014-11-11 05:09:57 UTC
Permalink
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:
***@us.ibm.com


"You have no responsibility to live up to what other people think you
ought to accomplish." -Richard Feynman (1918-1988)
Bernd Eckenfels
2014-11-12 00:44:40 UTC
Permalink
Am Tue, 11 Nov 2014 00:09:57 -0500
Post by Anil Ambati
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?
I think the reason for that is, that you can this way detect if the
process is still running: if it is locked, then it is running.

Of course this makes it hard to read the file. To work around this I
guess a native library is needed. (Or you execute "cmd /C type
file.pid"). Not sure if any component offers this (might be a good
addition to commons-daemon).

Gruss
Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: user-***@commons.apache.org
For additional commands, e-mail: user-***@commons.apache.org
Ian Emmons
2014-11-16 15:46:37 UTC
Permalink
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?
I think the reason for that is, that you can this way detect if the process is still running: if it is locked, then it is running.
Assuming that the pid file is created in the native code of procrun, then this could be solved by using the fine-grained sharing options of the Win32 API CreateFile (which is used to both create and open files). Specifically, procrun could call CreateFile so as to open the file in a mode where other processes can read the file but not write to it by passing FILE_SHARE_READ for the dwShareMode parameter.

This would allow other processes to read the file by opening for read-only access, and it would also allow another process to test if the procrun process is still running by opening with write access.
Of course this makes it hard to read the file. To work around this I guess a native library is needed. (Or you execute "cmd /C type file.pid"). Not sure if any component offers this (might be a good addition to commons-daemon).
I don’t think a native library or cmd’s type command will help here -- if the OS is enforcing exclusive access to the file, then that restriction will apply to all other processes.

-Ian
---------------------------------------------------------------------
To unsubscribe, e-mail: user-***@commons.apache.org
For additional commands, e-mail: user-***@commons.apache.org

Loading...