Maintenance Error on Login After Setting Up WordPress 6.6 Beta 1 on Localhost

[nithi22]

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

1. Download and install WordPress 6.6 Beta 1 on a localhost environment.
2. Complete the setup process as usual.
3. Attempt to log in to the WordPress dashboard.

Expected Results

1. The WordPress dashboard should be accessible, allowing me to log in without any issues.

Actual Results

1. The login attempt is blocked by a maintenance error message stating: "Briefly unavailable for scheduled maintenance. Check back in a minute."

[nithi22]

Attaching video for reference

​https://www.loom.com/share/26c253bbf0da429aab405d2631c80387?sid=ff8ed88d-a4d4-41f9-97bd-33a326abd954

[costdev]

Hi @nithi22, thanks for opening this ticket!

To help with possibly identifying the cause, can you repeat the process with the following modified steps?

1. Enter the database details and click Submit.
2. Add define( 'WP_DEBUG', true ); and define( 'WP_DEBUG_LOG' ); to the wp-config.php file.
3. Click the Run the installation.
4. Open debug.log, anonymise the contents, and post them here inside {{{ }}} tags (like {{{ contents here }}}).

Thanks!

[nithi22]

[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

[rajinsharwar]

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?

[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-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 ​213
• wp_update_themes() - Lines ​721 and ​732
• wp_update_plugins() - Lines ​440 and ​451
• download_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?

1. Add set_time_limit( 300 ); to wp-admin/includes/class-wp-automatic-updater.php on line 651 (just above the $is_debug = WP_DEBUG && WP_DEBUG_LOG;) line
2. Add the debugging lines from this comment to wp-config.php.
3. 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! 🙂

[nithins53]

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

[vivekawsm]

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

[nithi22]

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-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 ​213
• wp_update_themes() - Lines ​721 and ​732
• wp_update_plugins() - Lines ​440 and ​451
• download_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?

1. Add set_time_limit( 300 ); to wp-admin/includes/class-wp-automatic-updater.php on line 651 (just above the $is_debug = WP_DEBUG && WP_DEBUG_LOG;) line
2. Add the debugging lines from this comment to wp-config.php.
3. 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! 🙂

[nithins53]

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.

[vivekawsm]

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.

[akshay.shah5189]

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

[nithi22]

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.

[costdev]

In 58435:

Upgrade/Install: Delay automatic updates after installation.

After installation, the user is directed to the Log In page. This triggers the wp_schedule_update_checks() function which is hooked to init and schedules updates to run immediately if no other events exist. As a result of more robust use of maintenance mode for automatic updates added in [58128], the user may be presented with a maintenance mode screen just after installing WordPress.

To improve the user experience, this schedules core updates for 1 hour, plugin updates for 1.5 hours, and theme updates for 2 hours after installation.

Follow-up to [58128], [58139], [58308], [58309].

Props afragen, hellofromTonya, peterwilsoncc, nithi22, dd32.
Fixes #61457. See #58281, #61391.

[hellofromTonya]

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.

​Colin:

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 before shutdown completes).

[kanlukasz]

Hello,

Will there be any filter added to disable these log dumps?

e.g. here:
​https://github.com/WordPress/WordPress/blob/8d059b9fe25d2415c164b2f53e1a458ccdc20f99/wp-admin/includes/class-wp-automatic-updater.php#L672

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.

[chaion07]

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!

[chaion07]

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.

[aenea]

Replying to kanlukasz:

Hello,

Will there be any filter added to disable these log dumps?

e.g. here:
​https://github.com/WordPress/WordPress/blob/8d059b9fe25d2415c164b2f53e1a458ccdc20f99/wp-admin/includes/class-wp-automatic-updater.php#L672

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?

[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.

[desrosj]

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.

[acetafen]

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.

[nevzatbicer]

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-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 ​213
• wp_update_themes() - Lines ​721 and ​732
• wp_update_plugins() - Lines ​440 and ​451
• download_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?

1. Add set_time_limit( 300 ); to wp-admin/includes/class-wp-automatic-updater.php on line 651 (just above the $is_debug = WP_DEBUG && WP_DEBUG_LOG;) line
2. Add the debugging lines from ​this comment to wp-config.php.
3. 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.

[titsmaker]

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.