Opened 6 months ago
Last modified 11 days ago
#61391 reopened defect (bug)
Maintenance Error on Login After Setting Up WordPress 6.6 Beta 1 on Localhost
Reported by: | nithi22 | Owned by: | |
---|---|---|---|
Milestone: | 6.7.2 | Priority: | normal |
Severity: | critical | Version: | 6.6 |
Component: | Upgrade/Install | Keywords: | reporter-feedback needs-testing |
Focuses: | administration | Cc: |
Description
Bug Report
Description
After setting up WordPress 6.6 Beta 1 on a localhost environment, I encountered an issue where attempting to log into the WordPress dashboard results in a maintenance error message. The error displayed is:
"Briefly unavailable for scheduled maintenance. Check back in a minute."
Environment
- WordPress: 6.6-beta1
- PHP: 8.2.0
- Server: Apache/2.4.54 (Unix) OpenSSL/1.0.2u PHP/8.2.0 mod_wsgi/3.5 Python/2.7.18 mod_fastcgi/mod_fastcgi-SNAP-0910052141 mod_perl/2.0.11 Perl/v5.30.1
- Database: mysqli (Server: 5.7.39 / Client: mysqlnd 8.2.0)
- Browser: Firefox 126.0 (macOS)
- Theme: Twenty Twenty-Four 1.1
- MU-Plugins: None activated
- Plugins:
- WordPress Beta Tester 3.5.5
Steps to Reproduce
- Download and install WordPress 6.6 Beta 1 on a localhost environment.
- Complete the setup process as usual.
- Attempt to log in to the WordPress dashboard.
Expected Results
- The WordPress dashboard should be accessible, allowing me to log in without any issues.
Actual Results
- The login attempt is blocked by a maintenance error message stating: "Briefly unavailable for scheduled maintenance. Check back in a minute."
Attachments (3)
Change History (32)
#2
follow-up:
↓ 4
@
6 months ago
- Component changed from Administration to Upgrade/Install
- Keywords reporter-feedback added
- Milestone changed from Awaiting Review to 6.6
- Version set to trunk
Hi @nithi22, thanks for opening this ticket!
To help with possibly identifying the cause, can you repeat the process with the following modified steps?
- Enter the database details and click Submit.
- Add
define( 'WP_DEBUG', true );
anddefine( 'WP_DEBUG_LOG' );
to thewp-config.php
file. - Click the Run the installation.
- Open
debug.log
, anonymise the contents, and post them here inside{{{ }}}
tags (like{{{ contents here }}}
).
Thanks!
#4
in reply to:
↑ 2
@
6 months ago
[06-Jun-2024 12:41:34 UTC] Automatic updates starting...
[06-Jun-2024 12:41:37 UTC] Automatic updates complete.
[06-Jun-2024 12:41:43 UTC] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /Applications/MAMP/htdocs/wp_test/wp-includes/Requests/src/Transport/Curl.php on line 552.
This is what i am getting from debug.log
#5
@
6 months ago
Thanks for sharing that! Are you in Windows @nithi22? I suspect this is a file permission issue, it may be attempting to write continuously in the fwrite() function. 🤔
Quoting from the fwrite function page:
"Therefore, looping with repeated calls to fwrite() until the sum of number of bytes written equals the strlen() of the full value or expecting false on error will result in an infinite loop if the connection is lost."
What do you think @costdev?
#6
follow-ups:
↓ 10
↓ 28
@
6 months ago
@rajinsharwar I believe this occurred on MacOS based on the directory path included in this comment.
While the line mentioned in that log is an fwrite()
call, it seems that might just be the point at which the 30 seconds timeout occurred.
Given that the logs show that the Automatic updates complete.
line located here was hit, and no plugin or theme updates were detailed in-between starting...
and complete
, it seems that this error is not related to the Rollback Auto-Update feature introduced during the 6.6 release cycle.
In the code after this, there are HTTP requests sent in these locations:
wp_version_check()
- Lines 202 and 213wp_update_themes()
- Lines 721 and 732wp_update_plugins()
- Lines 440 and 451download_url()
- Lines 1172 and 1296
Depending on the environment, it may be that the execution of the automatic updates checks, including these HTTP requests and possibly others that I missed in my quick search, may run a little slower than other environments, and has exceeded the PHP default maximum_execution_time of 30 seconds.
@nithi22 Before starting the installation process, can you try this?
- Add
set_time_limit( 300 );
towp-admin/includes/class-wp-automatic-updater.php
on line 651 (just above the$is_debug = WP_DEBUG && WP_DEBUG_LOG;
) line - Add the debugging lines from this comment to
wp-config.php
. - Start the installation process.
Let us know whether this resolves the issue, and if not, please paste the (anonymized) contents of wp-content/debug.log
as you did before. Thanks! 🙂
#7
@
6 months ago
The issue is not limited to MacOS. The same error happens in the Windows environment also.
Environment
- WordPress: 6.6-beta1-58352
- PHP: 8.2.4
- Server: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.2.4
- Database: mysqli (Server: 10.4.28-MariaDB / Client: mysqlnd 8.2.4)
- Browser: Chrome 109.0.0.0 (Windows 10/11)
- Theme: Twenty Twenty-Four 1.1
- MU-Plugins: None activated
- Plugins:
- WordPress Beta Tester 3.5.5
#8
@
6 months ago
Environment
- WordPress: 6.6-beta1
- PHP: 8.2.4
- Server: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.2.4
- Database: mysqli (Server: 10.4.28-MariaDB / Client: mysqlnd 8.2.4)
- Browser: Chrome 125.0.0.0 (Windows 10/11)
- Theme: Twenty Twenty-Four 1.1
- MU-Plugins: None activated
- Plugins:
- WordPress Beta Tester 3.5.5
Actual Results
The issue existing on the Windows environment when the latest wp6.6-beta1 version setup
This ticket was mentioned in Slack in #core-upgrade-install by costdev. View the logs.
6 months ago
#10
in reply to:
↑ 6
@
6 months ago
Replying to costdev:
I installed the beta 2 following your guidelines, and the issue still persists. I defined the set_time_limit( 300 ); as you suggested and the end result is the same, the error message still occurs. However this time no maintenance file was created, but still the error message was shown. As stated, refreshing the web page loaded the dashboard perfectly.
and this is what i am getting from debug.log
[12-Jun-2024 05:19:36 UTC] Automatic updates starting... [12-Jun-2024 05:19:39 UTC] Automatic updates complete.
@rajinsharwar I believe this occurred on MacOS based on the directory path included in this comment.
While the line mentioned in that log is an
fwrite()
call, it seems that might just be the point at which the 30 seconds timeout occurred.
Given that the logs show that the
Automatic updates complete.
line located here was hit, and no plugin or theme updates were detailed in-betweenstarting...
andcomplete
, it seems that this error is not related to the Rollback Auto-Update feature introduced during the 6.6 release cycle.
In the code after this, there are HTTP requests sent in these locations:
wp_version_check()
- Lines 202 and 213wp_update_themes()
- Lines 721 and 732wp_update_plugins()
- Lines 440 and 451download_url()
- Lines 1172 and 1296Depending on the environment, it may be that the execution of the automatic updates checks, including these HTTP requests and possibly others that I missed in my quick search, may run a little slower than other environments, and has exceeded the PHP default maximum_execution_time of 30 seconds.
@nithi22 Before starting the installation process, can you try this?
- Add
set_time_limit( 300 );
towp-admin/includes/class-wp-automatic-updater.php
on line 651 (just above the$is_debug = WP_DEBUG && WP_DEBUG_LOG;
) line- Add the debugging lines from this comment to
wp-config.php
.- Start the installation process.
Let us know whether this resolves the issue, and if not, please paste the (anonymized) contents of
wp-content/debug.log
as you did before. Thanks! 🙂
#11
@
6 months ago
I also tested with the beta 2 and the problem still exists. This is the content of the debug.log file
[12-Jun-2024 06:29:48 UTC] Automatic updates starting...
[12-Jun-2024 06:29:55 UTC] Automatic updates complete.
#12
@
6 months ago
Same issue exist on WordPress 6.6 Beta 2. getting from debug.log file
[12-Jun-2024 05:50:28 UTC] Automatic updates starting...
[12-Jun-2024 05:50:31 UTC] Automatic updates complete.
#13
@
6 months ago
- Resolution set to worksforme
- Status changed from new to closed
It looks like it has been fixed by the team in beta version 2.0.
I have tested over the trunk.
For more reference here is the link : https://www.awesomescreenshot.com/video/28602293?key=6087fce321ff5aa79fa7ec4516370de0
#14
@
6 months ago
- Resolution worksforme deleted
- Status changed from closed to reopened
I also tested using the trunk version, and there are no issues. However, the issue still exists in the WordPress 6.6 Beta 2 version.
This ticket was mentioned in Slack in #core by nhrrob. View the logs.
5 months ago
#17
@
5 months ago
- Milestone changed from 6.6 to 6.7
The fatal error potential is pre-existing, i.e. not introduced in 6.6 cycle. With 6.6 RC1 happening today, moving to 6.7.
Was discussed in today's bug scrub.
@costdev shared:
The maintenance mode screen was the only thing that was caused by 6.6 to my knowledge. The report looks to be a timeout/cURL failure that produced a Fatal Error. This kills execution and would lead to a "stuck" maintenance screen any time maintenance mode is enabled when a Fatal Error occurs. In that respect, that's a pre-existing issue with maintenance mode/Core's Fatal Error handler.
To clarify: The when of the report's maintenance mode is what was related to 6.6, which we've now delayed. If the Fatal Error were to occur during the delayed updates/any other use of maintenance mode already in Core, the "stuck" maintenance mode screen would still occur. That part wasn't introduced in 6.6.
Me:
A fatal error is concerning, but is pre-existing. So as it wasn't introduced in 6.6 and a resolution won't land before RC1 today, thinking it's okay to punt to 6.7.
Yep that sounds right to me. We should explore maintenance mode, as well as the fatal error handler/
shutdown
event to see if there's something we can do there (such as delete.maintenance
beforeshutdown
completes).
#18
follow-up:
↓ 23
@
4 months ago
Hello,
Will there be any filter added to disable these log dumps?
Logs like these create unnecessary garbage and nothing more:
[29-Jul-2024 22:23:07 UTC] Automatic updates starting... [29-Jul-2024 22:23:08 UTC] Automatic updates complete. [30-Jul-2024 10:22:56 UTC] Automatic updates starting... [30-Jul-2024 10:22:56 UTC] Automatic updates complete. [30-Jul-2024 22:23:37 UTC] Automatic updates starting... [30-Jul-2024 22:23:38 UTC] Automatic updates complete. [31-Jul-2024 10:23:31 UTC] Automatic updates starting... [31-Jul-2024 10:23:32 UTC] Automatic updates complete. [31-Jul-2024 22:23:14 UTC] Automatic updates starting... [31-Jul-2024 22:23:15 UTC] Automatic updates complete. [01-Aug-2024 10:22:44 UTC] Automatic updates starting... [01-Aug-2024 10:22:44 UTC] Automatic updates complete.
Many developers use .log
to monitor some issues, using it with cron jobs, send logs elsewhere if something happen, etc., even in production (of course, we lock this file for public access).
We are looking for important things there, not trivial repetitive information.
Currently, one of my ideas is to use the sed -i
command and run it with cron to cut those lines, but it's not a very convenient way to do it.
This ticket was mentioned in Slack in #core by chaion07. View the logs.
3 months ago
#20
@
3 months ago
- Keywords needs-testing added
Thanks @nithi22 for reporting this. We reviewed this Ticket during a recent bug-scrub session and based on the discussion we feel the need for more testing. As much as we appreciate the feedback so far we want to emphasize on the need for latest test results. @nazmul111 has volunteered to run some tests and share the results accordingly. Additionally we appreciate any feedback from other contributors. Thanks.
Props to @nazmul111
Cheers!
This ticket was mentioned in Slack in #core by chaion07. View the logs.
8 weeks ago
#22
@
8 weeks ago
Hello @nazmul111 👋
I am following up on my most recent comment. Do you have an update regarding the Test Reports that you volunteered to share? Thank you for the hard work and efforts.
#23
in reply to:
↑ 18
@
7 weeks ago
Replying to kanlukasz:
Hello,
Will there be any filter added to disable these log dumps?
Logs like these create unnecessary garbage and nothing more:
[29-Jul-2024 22:23:07 UTC] Automatic updates starting... [29-Jul-2024 22:23:08 UTC] Automatic updates complete. [30-Jul-2024 10:22:56 UTC] Automatic updates starting... [30-Jul-2024 10:22:56 UTC] Automatic updates complete. [30-Jul-2024 22:23:37 UTC] Automatic updates starting... [30-Jul-2024 22:23:38 UTC] Automatic updates complete. [31-Jul-2024 10:23:31 UTC] Automatic updates starting... [31-Jul-2024 10:23:32 UTC] Automatic updates complete. [31-Jul-2024 22:23:14 UTC] Automatic updates starting... [31-Jul-2024 22:23:15 UTC] Automatic updates complete. [01-Aug-2024 10:22:44 UTC] Automatic updates starting... [01-Aug-2024 10:22:44 UTC] Automatic updates complete.Many developers use
.log
to monitor some issues, using it with cron jobs, send logs elsewhere if something happen, etc., even in production (of course, we lock this file for public access).
We are looking for important things there, not trivial repetitive information.
Currently, one of my ideas is to use the
sed -i
command and run it with cron to cut those lines, but it's not a very convenient way to do it.
I'd like to add my support to this comment. Having this unnecessary garbage in the log file is a nuisance. Why can't these messages be turned off?
#24
follow-up:
↓ 29
@
6 weeks ago
- Milestone changed from 6.7 to 6.7.1
@aenea I'd like to add my support to this comment. Having this unnecessary garbage in the log file is a nuisance. Why can't these messages be turned off?
This is unrelated to this bug report. Could you please open a new enhancement ticket for this request?
As for the initial report, it's unclear if this is still happening after [58435], or in general.
I'm going to move this to 6.7.1 and request more testing from the original reporters.
This ticket was mentioned in Slack in #core by desrosj. View the logs.
3 weeks ago
#26
@
3 weeks ago
- Milestone changed from 6.7.1 to 6.7.2
Because of a few bug reports opened since 6.7 was released, the Core team is evaluating the need for a short 6.7.1 cycle (possibly next week).
This issue was not introduced in 6.7, so it now falls outside of the focus for 6.7.1 as currently defined. To help prepare for this scenario in case it's decided to move forward, I'm going to punt this to the 6.7.2 milestone.
#27
@
2 weeks ago
The presence of the .maintenance file indicates an incomplete or interrupted update/maintenance process, leaving the site in an unintended maintenance mode. This issue could stem from:
A compatibility issue with PHP 8.2.
A conflict or bug introduced in WordPress 6.6 Beta 1 during maintenance-mode handling.
An environmental anomaly (e.g., database or filesystem issues in localhost setups).
Immediate Fix:
Access the WordPress root directory and delete the .maintenance file.
Confirm that the dashboard becomes accessible.
Investigate the Cause:
Check the PHP error logs (error_log) for any errors triggered during the login process.
Review server logs for anomalies that might indicate filesystem or execution halts.
Debug Maintenance Mode Handling:
Evaluate the behavior of _enable_maintenance_mode() in /wp-includes/load.php.
Verify whether _disable_maintenance_mode() is failing to run due to interruptions or logical errors.
Plugin Debugging:
Deactivate all plugins, especially WordPress Beta Tester, and test if the issue persists.
#28
in reply to:
↑ 6
@
2 weeks ago
Replying to costdev:
@rajinsharwar I believe this occurred on MacOS based on the directory path included in this comment.
While the line mentioned in that log is an
fwrite()
call, it seems that might just be the point at which the 30 seconds timeout occurred.
Given that the logs show that the
Automatic updates complete.
line located here was hit, and no plugin or theme updates were detailed in-betweenstarting...
andcomplete
, it seems that this error is not related to the Rollback Auto-Update feature introduced during the 6.6 release cycle.
In the code after this, there are HTTP requests sent in these locations:
wp_version_check()
- Lines 202 and 213wp_update_themes()
- Lines 721 and 732wp_update_plugins()
- Lines 440 and 451download_url()
- Lines 1172 and 1296Depending on the environment, it may be that the execution of the automatic updates checks, including these HTTP requests and possibly others that I missed in my quick search, may run a little slower than other environments, and has exceeded the PHP default maximum_execution_time of 30 seconds.
@nithi22 Before starting the installation process, can you try this?
- Add
set_time_limit( 300 );
towp-admin/includes/class-wp-automatic-updater.php
on line 651 (just above the$is_debug = WP_DEBUG && WP_DEBUG_LOG;
) line- Add the debugging lines from this comment to
wp-config.php
.- Start the installation process.
Let us know whether this resolves the issue, and if not, please paste the (anonymized) contents of
wp-content/debug.log
as you did before. Thanks! 🙂
Didnt work on me either. Problem continues still.
#29
in reply to:
↑ 24
@
11 days ago
Replying to desrosj:
@aenea I'd like to add my support to this comment. Having this unnecessary garbage in the log file is a nuisance. Why can't these messages be turned off?
This is unrelated to this bug report. Could you please open a new enhancement ticket for this request?
As for the initial report, it's unclear if this is still happening after [58435], or in general.
I'm going to move this to 6.7.1 and request more testing from the original reporters.
Why this is treated as an enhancement? These messages fill up the logs even of those users who never turned on automatic updates. To me it seems like a bug, there should be some checking if auto updates are enabled before sending these messages to log, otherwise they are completely useless. And a filter to turn it off.
Attaching video for reference
https://www.loom.com/share/26c253bbf0da429aab405d2631c80387?sid=ff8ed88d-a4d4-41f9-97bd-33a326abd954