Uploaded image for project: 'Log4php'
  1. Log4php
  2. LOG4PHP-238

Logging from (ppid) class destructor fails after forked child processes exit gracefully


    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.3.0
    • Fix Version/s: None
    • Component/s: Code
    • Labels:
    • Environment:
    • Flags:
      Patch, Important


      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)
      if ($this->closed) { return; }

      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(); }


      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.


        There are no comments yet on this issue.


          • Assignee:
            ljerabek Ludvik Jerabek
          • Votes:
            0 Vote for this issue
            1 Start watching this issue


            • Created: