Browse files

don't return a LogIterator on a broken handle

It might happen that we can't read from the logfile (and e.g. only append to it, which is the case on reasonable tuned SELinux systems). So in that case, we would return a LogIterator with a broken handle, that would then end up in an endless loop when trying to read from the logfile and a) spam the logfile (tons of messages written to it) and b) hog the cpu, as it's in an endless loop.

This happens for example in lib/Log/LogIterator.php when trying to seek through the file within next(), as the position never comes to an end.

Throwing an exception stops the endless loop before it begins and would give the possibility for upper layers to treat it appropriately. Though at the moment we just keep having a spinning wheel forever in admin interface's logging section. But at least no hogged cpus and spammed logs anymore... 

While working on the patch I saw #34 and it looks like, we also might have had a solution there, but nevertheless I think a LogIterator shouldn't even be created with an invalid handle.
  • Loading branch information...
duritong authored and icewind1991 committed Jan 29, 2017
1 parent a87a8e6 commit 39069108f99d463b1cb8bc944f3ef24324b9f43d
Showing with 5 additions and 1 deletion.
  1. +5 −1 lib/Controller/LogController.php
@@ -53,7 +53,11 @@ private function getLogIterator() {
foreach ($logClasses as $logClass) {
if (class_exists($logClass)) {
$handle = fopen($logClass::getLogFilePath(), 'rb');
return new LogIterator($handle, $dateFormat);
if ($handle) {
return new LogIterator($handle, $dateFormat);
else {
throw new \Exception("Error while opening ".$logClass::getLogFilePath());
throw new \Exception('Can\'t find log class');

0 comments on commit 3906910

Please sign in to comment.