[jira] [Reopened] (DAEMON-65) [daemon] runs as multiple instances, does not use PID file logic

2017-11-14 Thread Mark Thomas (JIRA)

 [ 
https://issues.apache.org/jira/browse/DAEMON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas reopened DAEMON-65:
---

> [daemon] runs as multiple instances, does not use PID file logic
> 
>
> Key: DAEMON-65
> URL: https://issues.apache.org/jira/browse/DAEMON-65
> Project: Commons Daemon
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: Operating System: Linux
> Platform: PC
>Reporter: bernard
>Priority: Critical
>
> jsvc writes its own pid file but it appears that it does not have a logic that
> secures its own integrity.
> Multiple duplicate processes can be created simply by issuing the same jsvc
> command multiple times. The created processes cannot be killed using the pppid
> file for obvious reasons.
> 1) jsvc should terminate prematurely if it finds its own pid file.
> 2) jsvc should delete its own pid file when killed.
> If 1) and 2) are not acceptable because (hypothetically, because I don't know
> the specifications) the specifications require that the caller incorporates 
> this
> logic, then jsvc should not write a pid file.
> Why do i think so?
> Depending on implementation, the risk of malfunctioning is much higher if the
> pid file is managed across different execution environments.
> One major reason is that these environments are not usually maintained by the
> same person.
> I guess one might try to get a file system lock on the pid file before 
> launching
> the java program.
> Please excuse my ignorance if I am misinterpreting the daemon functionality in
> any way. I have tried to get responses from 3 relevant mailing lists,
> commons-user, commons-dev and tomcat-user, but nobody replied.
> I am not a Linux programmer and I would not be surprised if this kind of
> programming problem (uniqueness of id'd processes on one machine) has a 
> standard
> solution under Linux.
> Because



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] Reopened: (DAEMON-65) [daemon] runs as multiple instances, does not use PID file logic

2008-01-10 Thread Dennis Lundberg (JIRA)

 [ 
https://issues.apache.org/jira/browse/DAEMON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg reopened DAEMON-65:
---


> [daemon] runs as multiple instances, does not use PID file logic
> 
>
> Key: DAEMON-65
> URL: https://issues.apache.org/jira/browse/DAEMON-65
> Project: Commons Daemon
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: Operating System: Linux
> Platform: PC
>Reporter: bernard
>Priority: Critical
>
> jsvc writes its own pid file but it appears that it does not have a logic that
> secures its own integrity.
> Multiple duplicate processes can be created simply by issuing the same jsvc
> command multiple times. The created processes cannot be killed using the pppid
> file for obvious reasons.
> 1) jsvc should terminate prematurely if it finds its own pid file.
> 2) jsvc should delete its own pid file when killed.
> If 1) and 2) are not acceptable because (hypothetically, because I don't know
> the specifications) the specifications require that the caller incorporates 
> this
> logic, then jsvc should not write a pid file.
> Why do i think so?
> Depending on implementation, the risk of malfunctioning is much higher if the
> pid file is managed across different execution environments.
> One major reason is that these environments are not usually maintained by the
> same person.
> I guess one might try to get a file system lock on the pid file before 
> launching
> the java program.
> Please excuse my ignorance if I am misinterpreting the daemon functionality in
> any way. I have tried to get responses from 3 relevant mailing lists,
> commons-user, commons-dev and tomcat-user, but nobody replied.
> I am not a Linux programmer and I would not be surprised if this kind of
> programming problem (uniqueness of id'd processes on one machine) has a 
> standard
> solution under Linux.
> Because

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.