If I stop the database server of my Drupal site and browse it, I get an error page with:
PDOException: SQLSTATE[HY000] [2013] Lost connection to MySQL server at 'reading initial communication packet', system error: 111 in lock_may_be_available() (line 167 of /var/www/includes/lock.inc).

My concern is that I do not see any error in either web server error log file or syslog file.

I guess such errors were intended to go into watchdog (cf. line 214 of includes/errors.inc) but in such case module_implements('watchdog') does not return anything as the modules list cannot be retrieved.
I would suggest using error_log() in _drupal_log_erro() for any fatal error. Any opinion about that?

CommentFileSizeAuthor
#10 log_errors_without_db-1536868-10.patch863 bytessuperspring
#5 log_errors_without_db-1536868-5.patch895 bytessuperspring

Comments

marcingy’s picture

marcingy commented
Priority: Major » Normal

This is not a major bug.

sdelbosc’s picture

sdelbosc commented

I do not agree with the priority you used.
We must be aware of any service outage and due to this issue we may miss some of them. That is the reason why I used major priority.

marcingy’s picture

marcingy commented

But the priority is not major in terms of the drupal project - it might be for your business but not for the project.

sdelbosc’s picture

sdelbosc commented

Understood.

superspring’s picture

superspring commented
Version: 7.9 » 8.x-dev
Status: Active » Needs review
StatusFileSize
new log_errors_without_db-1536868-5.patch895 bytes

This patch logs exceptions to the error log when they are thrown in odd places (such as when the database is down).

adamdicarlo’s picture

adamdicarlo commented

Looks like the only code added is the error_log() call - the rest of the patch fixes the comment line length and fixes indentation. Looks good to me.

josh waihi’s picture

josh waihi commented
Status: Needs review » Reviewed & tested by the community

RTBC as per #6

catch’s picture

catch
he/him
Primary language English
commented
Version: 8.x-dev » 7.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)
Issue tags: +Needs backport to D7

This comment isn't going to be true when error_displayable() is converted to config():

+    // If we are displaying errors, then do so with no possibility of a further
+    // uncaught exception being thrown.
+    require_once DRUPAL_ROOT . '/core/includes/errors.inc';
+    if (error_displayable()) {

That's not the fault of this patch so I opened #1845646: error_displayable() cannot be converted from variable system safely. Committed/pushed to 8.x.

Is this worth a Drupal 7 backport?

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

It's possible that this might have been the fix for the sporadically appearing PHP notice mentioned in #1158322: Add backtrace to all errors — I did not verify that though.

superspring’s picture

superspring commented
Status: Patch (to be ported) » Needs review
StatusFileSize
new log_errors_without_db-1536868-10.patch863 bytes

Same patch in D7.

  • catch committed 62f6333 on 8.3.x 
    Issue #1536868 by superspring: Fixed No trace when database is down.

  • catch committed 62f6333 on 8.3.x 
    Issue #1536868 by superspring: Fixed No trace when database is down.

  • catch committed 62f6333 on 8.4.x 
    Issue #1536868 by superspring: Fixed No trace when database is down.

  • catch committed 62f6333 on 8.4.x 
    Issue #1536868 by superspring: Fixed No trace when database is down.

Status: Needs review » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.