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.