[
https://issues.apache.org/jira/browse/LOG4PHP-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ludvik Jerabek updated LOG4PHP-238:
-----------------------------------
Summary: Logging from class destructor fails when after forked child
processes exit gracefully (was: Logging from class destructor fails when from
forked child processes)
> Logging from class destructor fails when 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.
> 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)
