Zend Framework

Shared memory segment and semaphore not being deleted in ZendX_Console_Process_Unix

Details

  • Type: Bug Bug
  • Status: Reopened Reopened
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 1.7.2
  • Fix Version/s: None
  • Component/s: ZendX_Console_Process_Unix
  • Labels:
    None

Description

The shared memory segment and semaphore files (*.shm and *.sem) are not being deleted when the process is stopped. In the _cleanProcessContext method, on lines 387 and 388, there are the following statements, which are no-ops:

$this->_ipcSegFile;
$this->_ipcSemFile;

The above is probably a typo. IMO, it should be as follows:

unlink($this->_ipcSegFile);
unlink($this->_ipcSemFile);

I can submit a patch if needed. Let me know the steps I need to take if this is preferred.

Issue Links

This issue is related to:
ZF-6047 'Unable to create SHM segments for process communications' in long running script Major Open

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ben Scholzen added a comment -

When creating a patch, include a new unit test which makes sure, that the new case works. Also make sure, that all the other unit tests still work after your modifications.

Show
Ben Scholzen added a comment - When creating a patch, include a new unit test which makes sure, that the new case works. Also make sure, that all the other unit tests still work after your modifications.
Hide
Permalink
Benjamin Eberlei added a comment -

take it ben

Show
Benjamin Eberlei added a comment - take it ben
Hide
Permalink
Ben Scholzen added a comment -

Fixed with r14345 and merged into 1.7 release branch with r14346.

Show
Ben Scholzen added a comment - Fixed with r14345 and merged into 1.7 release branch with r14346.
Hide
Permalink
James Dempster added a comment -

Is there a need to use ftok to create an id? I think that a random number might do?
Also I don't think the files are bing removed because _cleanProcessContext is only ever called if your killing the process by using stop. So a process that successfully completes never gets cleaned up.

Show
James Dempster added a comment - Is there a need to use ftok to create an id? I think that a random number might do? Also I don't think the files are bing removed because _cleanProcessContext is only ever called if your killing the process by using stop. So a process that successfully completes never gets cleaned up.
Hide
Permalink
Ben Scholzen added a comment -

Hm, actually it's not required if I read it right from the php.net comments of ftok. I'll look into it again.

Show
Ben Scholzen added a comment - Hm, actually it's not required if I read it right from the php.net comments of ftok. I'll look into it again.
Hide
Permalink
Dominik Krebs added a comment -

It seems the created ipc-segments are not removed after running the _run-function.
The stop function is not being executed after the process terminates.

Show
Dominik Krebs added a comment - It seems the created ipc-segments are not removed after running the _run-function. The stop function is not being executed after the process terminates.
Hide
Permalink
Ben Scholzen added a comment -

Post 1.8 I will take a deeper look and do some internal refactoring to get rid of this issue.

Show
Ben Scholzen added a comment - Post 1.8 I will take a deeper look and do some internal refactoring to get rid of this issue.
Hide
Permalink
Ben Scholzen added a comment -

Post 1.8 I will take a deeper look and do some internal refactoring to get rid of this issue.

Show
Ben Scholzen added a comment - Post 1.8 I will take a deeper look and do some internal refactoring to get rid of this issue.
Hide
Permalink
James Dempster added a comment - - edited

try adding this

/**
 * Destructor
 *
 * Cleans up
 */
public function __destruct() {
    // mark the shared memory object for deletion
    // read and write can still happen
    // no more process can attach
    // when the last process is detached then the
    // memory object is deleted
    shmop_delete($this->_internalIpcKey);
    shmop_close($this->_internalIpcKey);
}
Show
James Dempster added a comment - - edited try adding this 
/**
 * Destructor
 *
 * Cleans up
 */
public function __destruct() {
    // mark the shared memory object for deletion
    // read and write can still happen
    // no more process can attach
    // when the last process is detached then the
    // memory object is deleted
    shmop_delete($this->_internalIpcKey);
    shmop_close($this->_internalIpcKey);
}
Hide
Permalink
Jessie Hernandez added a comment -

FYI, in the updated version from ZF 1.9 I ran into cases where the shared memory segments remained for a child even though the child was killed. Since the SHM segments remained, and isRunning is set to false only after everything has been cleaned up, the parent process remained running indefinitely.

FWIW, the fix I made for this was to call $this->stop() right before the exit(0) call in the start() method (see below). Before the change my script would always hang, and after this change the script consistently ends successfully after the children are stopped. I still don't understand fully why it works, as from what I see in the class, $this->_pid is null for the child, and stop() only cleans up the process context if $this->_pid has a nonzero value.

// Destroy the child after _run() execution. Required to avoid
// unuseful child processes after execution
$this->stop();
exit(0);

Show
Jessie Hernandez added a comment - FYI, in the updated version from ZF 1.9 I ran into cases where the shared memory segments remained for a child even though the child was killed. Since the SHM segments remained, and isRunning is set to false only after everything has been cleaned up, the parent process remained running indefinitely. FWIW, the fix I made for this was to call $this->stop() right before the exit(0) call in the start() method (see below). Before the change my script would always hang, and after this change the script consistently ends successfully after the children are stopped. I still don't understand fully why it works, as from what I see in the class, $this->_pid is null for the child, and stop() only cleans up the process context if $this->_pid has a nonzero value. // Destroy the child after _run() execution. Required to avoid // unuseful child processes after execution $this->stop(); exit(0);

People

Vote (5)
Watch (5)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Zend Framework. Try JIRA - bug tracking software for your team.