adam/Piwigo
1
0 Fork 0
mirror of https://github.com/Piwigo/Piwigo.git synced 2026-10-30 21:52:00 +01:00
Code Issues 657 Packages Projects Releases Wiki Activity

Uncaught RuntimeException in Logger crashes the whole page (including admin) when the log directory is not writable #2232

New Issue
Open
opened 2026-10-05 01:10:32 +02:00 by adam · 0 comments
adam commented 2026-10-05 01:10:32 +02:00
Owner
Copy link
Copy source

Hello,

While helping a user on the forum (fr.piwigo.org/forum/viewtopic.php?pid=245721#p245721), I noticed a fragility in the logging system that I wanted to report, in case it's worth a small hardening.

Context from the forum thread

A user (Piwigo 16.4.0, PHP 8.5.9, MariaDB 12.3.2, SELinux enabled) got a fatal error and lost access to the admin panel because _data/logs was not writable (SELinux context issue on their server). The exact message was:

Fatal error: Uncaught RuntimeException: The file could not be written to. Check that appropriate permissions have been set.

What I found in the code

  • In include/Logger.class.php, Logger::open() throws a RuntimeException when the target log file/directory isn't writable, and write() calls open() on every log call without catching anything.
  • In include/common.inc.php, $logger = new Logger(...) is not wrapped in a try/catch — unlike pwg_db_connect() just above it, which is.
  • No global set_exception_handler() is registered in common.inc.php to turn an uncaught exception into a graceful error page.
  • The default log level (include/config_default.inc.php) is DEBUG, so logging is active by default, and $logger->info(...)/debug(...) calls happen fairly early/often (e.g. in functions.inc.php).

Effect

If the log directory becomes unwritable for any reason (permissions, SELinux context, full disk, read-only filesystem, etc.), the first log call of the request throws an uncaught exception and the whole page dies with a raw PHP fatal error — including the admin panel, which is precisely where one would go to diagnose or fix the issue.

Possible direction (just a suggestion, happy to be told this was already considered)

Would it make sense for logging failures to degrade gracefully instead of being fatal — e.g. catching the exception in Logger::log()/write() and silently disabling logging for the rest of the request (maybe with a one-time trigger_error(E_USER_WARNING)) rather than letting it propagate? That way a logging-only problem wouldn't take down the whole application.

Happy to provide more details or test a patch if useful. Thanks for maintaining Piwigo!

Hello, While helping a user on the forum ([fr.piwigo.org/forum/viewtopic.php?pid=245721#p245721](https://fr.piwigo.org/forum/viewtopic.php?pid=245721#p245721)), I noticed a fragility in the logging system that I wanted to report, in case it's worth a small hardening. **Context from the forum thread** A user (Piwigo 16.4.0, PHP 8.5.9, MariaDB 12.3.2, SELinux enabled) got a fatal error and lost access to the admin panel because `_data/logs` was not writable (SELinux context issue on their server). The exact message was: ``` Fatal error: Uncaught RuntimeException: The file could not be written to. Check that appropriate permissions have been set. ``` **What I found in the code** - In `include/Logger.class.php`, `Logger::open()` throws a `RuntimeException` when the target log file/directory isn't writable, and `write()` calls `open()` on every log call without catching anything. - In `include/common.inc.php`, `$logger = new Logger(...)` is not wrapped in a try/catch — unlike `pwg_db_connect()` just above it, which is. - No global `set_exception_handler()` is registered in `common.inc.php` to turn an uncaught exception into a graceful error page. - The default log level (`include/config_default.inc.php`) is `DEBUG`, so logging is active by default, and `$logger->info(...)`/`debug(...)` calls happen fairly early/often (e.g. in `functions.inc.php`). **Effect** If the log directory becomes unwritable for any reason (permissions, SELinux context, full disk, read-only filesystem, etc.), the first log call of the request throws an uncaught exception and the whole page dies with a raw PHP fatal error — including the admin panel, which is precisely where one would go to diagnose or fix the issue. **Possible direction (just a suggestion, happy to be told this was already considered)** Would it make sense for logging failures to degrade gracefully instead of being fatal — e.g. catching the exception in `Logger::log()`/`write()` and silently disabling logging for the rest of the request (maybe with a one-time `trigger_error(E_USER_WARNING)`) rather than letting it propagate? That way a logging-only problem wouldn't take down the whole application. Happy to provide more details or test a patch if useful. Thanks for maintaining Piwigo! <!-- github-sync-id:5352154721 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/Piwigo#2232