[
https://issues.apache.org/jira/browse/LOG4PHP-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ludvik Jerabek updated LOG4PHP-238:
-----------------------------------
Description:
The issue appear to only manifest itself when implementing class level logging.
"$this->closed" will evaluate to true when called from a parent::__destruct()
of a forked child processes. I assume the file handle is most likely closed by
a forked child closing when it exits.
Snippet from LoggerAppender.php
public function doAppend(LoggerLoggingEvent $event)
{
{color:red} if ($this->closed) {
return;
}{color}
if (!$this->isAsSevereAsThreshold($event->getLevel())) {
return;
}
$filter = $this->getFirstFilter();
while ($filter !== null) {
switch ($filter->decide($event)) {
case LoggerFilter::DENY:
return;
case LoggerFilter::ACCEPT:
return $this->append($event);
case LoggerFilter::NEUTRAL:
$filter = $filter->getNext();
}
}
$this->append($event);
}
To recreate the issue create a php daemon:
1. Create a parent object which performs one (or more) a pcntl_fork calls.
Ensure the class object has a class level logger. Log from __construct() and
__destruct().
2 The parent should handle SIG_TERM and signal the child processes to exit.
3. The parent uses pcntl_wait to wait for the child processes to exit cleanly.
If possible use child objects with class level logging too to see how children
react.
4. When the parent has completed waiting on the children to exit, the parent's
"__destruct" will not write to the log.
Since every child gets a copy of the members variables and open file
descriptors it seems that when forked children exit. It *somehow* impacts the
ability of the parent to write to the logger object associated with the parent
class. I eventually gave up troubleshooting due to time limitations, and
resorted using direct syslog() calls throughout.
When I get some time I may be able to upload some sample code to demonstrate
the bug.
was:
The issue appear to only manifest itself when implementing class level logging.
"$this->closed" will evaluate to true when called from a parent::__destruct()
of a forked child processes. I assume the file handle is most likely closed by
a forked child closing when it exits.
public function doAppend(LoggerLoggingEvent $event)
{
{color:red} if ($this->closed) {
return;
}{color}
if (!$this->isAsSevereAsThreshold($event->getLevel())) {
return;
}
$filter = $this->getFirstFilter();
while ($filter !== null) {
switch ($filter->decide($event)) {
case LoggerFilter::DENY:
return;
case LoggerFilter::ACCEPT:
return $this->append($event);
case LoggerFilter::NEUTRAL:
$filter = $filter->getNext();
}
}
$this->append($event);
}
To recreate the issue create a php daemon:
1. Create a parent object which performs one (or more) a pcntl_fork calls.
Ensure the class object has a class level logger. Log from __construct() and
__destruct().
2 The parent should handle SIG_TERM and signal the child processes to exit.
3. The parent uses pcntl_wait to wait for the child processes to exit cleanly.
If possible use child objects with class level logging too to see how children
react.
4. When the parent has completed waiting on the children to exit, the parent's
"__destruct" will not write to the log.
Since every child gets a copy of the members variables and open file
descriptors it seems that when forked children exit. It *somehow* impacts the
ability of the parent to write to the logger object associated with the parent
class. I eventually gave up troubleshooting due to time limitations, and
resorted using direct syslog() calls throughout.
When I get some time I may be able to upload some sample code to demonstrate
the bug.
> Logging from (ppid) class destructor fails after forked child processes exit
> gracefully
> ----------------------------------------------------------------------------------------
>
> Key: LOG4PHP-238
> URL: https://issues.apache.org/jira/browse/LOG4PHP-238
> Project: Log4php
> Issue Type: Bug
> Components: Code
> Affects Versions: 2.3.0
> Environment: Linux virtual-machine 4.4.0-79-generic #100-Ubuntu SMP
> Wed May 17 19:58:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> Php Version:
> PHP 7.0.18-0ubuntu0.16.04.1 (cli) ( NTS )
> Copyright (c) 1997-2017 The PHP Group
> Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
> with Zend OPcache v7.0.18-0ubuntu0.16.04.1, Copyright (c) 1999-2017, by
> Zend Technologies
> with Xdebug v2.4.0, Copyright (c) 2002-2016, by Derick Rethans
> Reporter: Ludvik Jerabek
>
> The issue appear to only manifest itself when implementing class level
> logging.
> "$this->closed" will evaluate to true when called from a parent::__destruct()
> of a forked child processes. I assume the file handle is most likely closed
> by a forked child closing when it exits.
> Snippet from LoggerAppender.php
> public function doAppend(LoggerLoggingEvent $event)
> {
> {color:red} if ($this->closed) {
> return;
> }{color}
> if (!$this->isAsSevereAsThreshold($event->getLevel())) {
> return;
> }
> $filter = $this->getFirstFilter();
> while ($filter !== null) {
> switch ($filter->decide($event)) {
> case LoggerFilter::DENY:
> return;
> case LoggerFilter::ACCEPT:
> return $this->append($event);
> case LoggerFilter::NEUTRAL:
> $filter = $filter->getNext();
> }
> }
> $this->append($event);
> }
> To recreate the issue create a php daemon:
> 1. Create a parent object which performs one (or more) a pcntl_fork calls.
> Ensure the class object has a class level logger. Log from __construct() and
> __destruct().
> 2 The parent should handle SIG_TERM and signal the child processes to exit.
> 3. The parent uses pcntl_wait to wait for the child processes to exit
> cleanly. If possible use child objects with class level logging too to see
> how children react.
> 4. When the parent has completed waiting on the children to exit, the
> parent's "__destruct" will not write to the log.
> Since every child gets a copy of the members variables and open file
> descriptors it seems that when forked children exit. It *somehow* impacts the
> ability of the parent to write to the logger object associated with the
> parent class. I eventually gave up troubleshooting due to time limitations,
> and resorted using direct syslog() calls throughout.
> When I get some time I may be able to upload some sample code to demonstrate
> the bug.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
