We have random 503 errors on the server for the pages like user/login with the php fatal error in the logs.
This issue is not consistent and I have not found exact steps to reproduce it.
My guess that it may appear only when authcache is used in combination with domain access module (as we have) or any other module that is included from in settings.php.
I was not able to reproduce issue locally, but see a potential problem using the drupal_get_path_alias() function on exit, that may also be related to that hook_exist is executed on cached page.
Do you think it may be reasonable to do full bootstrap in _authcache_shutdown_save_page and if no - what can be an alternative?
Comment | File | Size | Author |
---|---|---|---|
#5 | 2060613-no-cache-when-not-bootstrapped-fully.patch | 483 bytes | znerol |
#4 | 2060613-safe_exit_drupal_bootstrap_full-4.patch | 540 bytes | dasha_v |
#1 | 2054251-separate_rpx_ui_from_widgets-1.patch | 348 bytes | dasha_v |
Comments
Comment #1
dasha_v CreditAttribution: dasha_v commentedI have concerns about full bootstrap, but have no other solution. Please review.
Comment #2
znerol CreditAttribution: znerol commentedOk, lets figure that out. Core calls the exit-hook in four different places (
git grep -n -p -C3 invoke.*exit
):ajax_footer()
Interesting fact here: The hook gets only invoked when drupal is fully bootstrapped. Therefore it cannot be the cause of the problem.
_drupal_bootstrap_page_cache()
Rereading this function I think the following circumstances can lead to the invocation with low bootstrap level:
nocache
ornocache_temp
cookie.page_cache_without_database
orcache
is set toTRUE
.In this case it would be possible that a cached page is delivered by
_drupal_bootstrap_page_cache()
andhook_exit
gets invoked.Would you mind placing the following snipped into your
settings.php
and report back whether this solves the problem:drupal_page_footer()
This is where the hook is invoked after a page has been rendered using a full bootstrap. I do not think that this invocation causes problems.
drupal_exit()
This one is again guarded against low bootstrap levels.
BTW: I guess the patch from #1 was intended for another issue...
Comment #3
dasha_v CreditAttribution: dasha_v commentedRight, my mistake with the path. Unfortunately can not delete it.
As I said, as I was not able to reproduce this consistently I put this on hold. It is not in core, and not on authcache, it is somewhere in combination of other contributed modules with it.
Today, accidentally I've found that the reason why drupal_get_bootstrap_phase() == DRUPAL_BOOTSTRAP_FULL that you assume is safe can be not working.
It is in autologout module, here:
As you see - it is doing drupal_theme_initialize, that has these code inside:
And now, as a result drupal_get_bootstrap_phase() will have it as DRUPAL_BOOTSTRAP_DATABASE (I assume).
Comment #4
dasha_v CreditAttribution: dasha_v commentedIt is still not clear for me why this happened, but here is initial path that was lost.
Comment #5
znerol CreditAttribution: znerol commentedThere was a very similar problem in the 2.x-dev branch: #2075603: Fatal error if authcache_exit is invoked when not fully bootstrapped. The culprit was the shurly-module, looking up short-urls from within
hook_boot
and then callinghook_exit
from there.I my opinion it is saver to not store a page to the cache, when
DRUPAL_BOOTSTRAP_FULL
was not reached beforehook_exit
gets called. What do you think?Concerning bootstrapping: When
hook_init
is called the bootstrapping level is guaranteed to beDRUPAL_BOOTSTRAP_FULL
. Also it only can rise from lover to higher levels. Whendrupal_bootstrap(DRUPAL_BOOTSTRAP_DATABASE);
is called from a higher level, no action will be performed.Comment #6
dasha_v CreditAttribution: dasha_v commentedThank you! #5 make perfect sense.
Comment #7
znerol CreditAttribution: znerol commented@dasha_v: Does it also fix the problem you reported?
Comment #8
znerol CreditAttribution: znerol commentedCommitted and pushed: 6cbdf62.
Comment #9
znerol CreditAttribution: znerol commentedComment #10
znerol CreditAttribution: znerol commented