Make WordPress Core

Opened 5 weeks ago

Last modified 3 weeks ago

#61391 reopened defect (bug)

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

Reported by: nithi22's profile nithi22 Owned by:
Milestone: 6.7 Priority: normal
Severity: critical Version: trunk
Component: Upgrade/Install Keywords: reporter-feedback
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

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

Attachments (3)

6.6maitenance.jpg (44.1 KB) - added by nithins53 5 weeks ago.
Screenshot 2024-06-11 101919.png (44.3 KB) - added by vivekawsm 5 weeks ago.
Screenshot 2024-06-12 125307.png (14.4 KB) - added by vivekawsm 5 weeks ago.

Download all attachments as: .zip

Change History (20)

#2 follow-up: @costdev
5 weeks 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?

  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!

#3 @nithi22
5 weeks ago

Last edited 5 weeks ago by nithi22 (previous) (diff)

#4 in reply to: ↑ 2 @nithi22
5 weeks 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

Last edited 5 weeks ago by nithi22 (previous) (diff)

#5 @rajinsharwar
5 weeks 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-up: @costdev
5 weeks 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:

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! 🙂

Last edited 5 weeks ago by costdev (previous) (diff)

#7 @nithins53
5 weeks 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 @vivekawsm
5 weeks 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.


5 weeks ago

#10 in reply to: ↑ 6 @nithi22
5 weeks 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.
https://i.imgur.com/xoo90c3.png

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:

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! 🙂

#11 @nithins53
5 weeks 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 @vivekawsm
5 weeks 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.

Last edited 5 weeks ago by vivekawsm (previous) (diff)

#13 @akshay.shah5189
4 weeks 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 @nithi22
4 weeks 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.

#15 @costdev
4 weeks ago

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.

This ticket was mentioned in Slack in #core by nhrrob. View the logs.


3 weeks ago

#17 @hellofromTonya
3 weeks 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.

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

Note: See TracTickets for help on using tickets.