Admin login no longer working

[sibeguy]

My site auto updated to 5.5.3 and my admin login is no longer working.

I go to the login page, enter the username/password. It gives no error and remains on the login page.

[audrasjb]

Hi @sibeguy, welcome to WordPress Trac and thanks for opening this ticket,

I can't reproduce this issue on a fresh install.
Does the issue still occurs with all plugins deactivated?

Thanks,
Jb

[sibeguy]

Nope, deactivating plug-ins doesn't fix the issue.

I suspect it is a database issue. I have Moodle installed on 3 domains being hosted and using the same MySQL database. They're all failing with the error "unable to write to database". My hosting company could find no issues with the MySQL server, purged the cache and still getting the same errors.

I wonder if the 5.3.3 made some database configuration change.

[sibeguy]

Below is the error_log messages...

[01-Nov-2020 19:02:41 UTC] WordPress database error Operation not allowed when innodb_forced_recovery > 0. for query UPDATE `wpa9_options` SET `option_value` = '1.3.2' WHERE `option_name` = 'pagelayer_version' made by require('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, pagelayer_load_plugin, pagelayer_update_check, update_option
[01-Nov-2020 19:02:41 UTC] WordPress database error Operation not allowed when innodb_forced_recovery > 0. for query INSERT INTO `wpa9_options` (`option_name`, `option_value`, `autoload`) VALUES ('_transient_doing_cron', '1604257361.3942909240722656250000', 'yes') ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`) made by require('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('init'), WP_Hook->do_action, WP_Hook->apply_filters, wp_cron, spawn_cron, set_transient, add_option
[01-Nov-2020 13:02:41 America/Chicago] PHP Warning:  Version warning: Imagick was compiled against Image Magick version 1654 but version 1650 is loaded. Imagick will run but may behave surprisingly in Unknown on line 0
[01-Nov-2020 19:02:42 UTC] WordPress database error Operation not allowed when innodb_forced_recovery > 0. for query UPDATE `wpa9_usermeta` SET `meta_value` = 'a:1:{s:64:\"498269534cc73bf70c8afa43a26ddebb9027c2ba92ecdb1eec529a4a2c244581\";a:4:{s:10:\"expiration\";i:1604430162;s:2:\"ip\";s:12:\"99.110.53.90\";s:2:\"ua\";s:78:\"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0\";s:5:\"login\";i:1604257362;}}' WHERE `user_id` = 1 AND `meta_key` = 'session_tokens' made by wp_signon, wp_set_auth_cookie, WP_Session_Tokens->create, WP_Session_Tokens->update, WP_User_Meta_Session_Tokens->update_session, WP_User_Meta_Session_Tokens->update_sessions, update_user_meta, update_metadata
[01-Nov-2020 19:02:42 UTC] WordPress database error Operation not allowed when innodb_forced_recovery > 0. for query INSERT INTO `wpa9_usermeta` (`user_id`, `meta_key`, `meta_value`) VALUES (1, 'wc_last_active', '1604188800') made by wp_signon, do_action('wp_login'), WP_Hook->do_action, WP_Hook->apply_filters, wc_user_logged_in, wc_update_user_last_active, update_user_meta, update_metadata, add_metadata
[01-Nov-2020 19:02:42 UTC] WordPress database error Operation not allowed when innodb_forced_recovery > 0. for query INSERT INTO `wpa9_usermeta` (`user_id`, `meta_key`, `meta_value`) VALUES (1, '_woocommerce_load_saved_cart_after_login', '1') made by wp_signon, do_action('wp_login'), WP_Hook->do_action, WP_Hook->apply_filters, wc_user_logged_in, update_user_meta, update_metadata, add_metadata
[01-Nov-2020 19:02:42 UTC] WordPress database error Operation not allowed when innodb_forced_recovery > 0. for query UPDATE `wpa9_options` SET `option_value` = '1.3.2' WHERE `option_name` = 'pagelayer_version' made by require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, pagelayer_load_plugin, pagelayer_update_check, update_option

[01-Nov-2020 19:02:45 UTC] WordPress database error Operation not allowed when innodb_forced_recovery > 0. for query UPDATE `wpa9_options` SET `option_value` = '1.3.2' WHERE `option_name` = 'pagelayer_version' made by require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, pagelayer_load_plugin, pagelayer_update_check, update_option
[01-Nov-2020 13:02:46 America/Chicago] PHP Warning:  Version warning: Imagick was compiled against Image Magick version 1654 but version 1650 is loaded. Imagick will run but may behave surprisingly in Unknown on line 0
[01-Nov-2020 19:02:47 UTC] WordPress database error Operation not allowed when innodb_forced_recovery > 0. for query UPDATE `wpa9_options` SET `option_value` = '1.3.2' WHERE `option_name` = 'pagelayer_version' made by require('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, pagelayer_load_plugin, pagelayer_update_check, update_option

[sibeguy]

In doing further research on the innodb_forced_recovery error I discovered this article.

​https://stackoverflow.com/questions/25155777/operation-not-allowed-when-innodb-forced-recovery-0-sqlyog

[sibeguy]

In running the mysql query...

SELECT @@global.read_only;

The result returns...

@@global.read_only

0

[hellofromTonya]

I'm sorry you're having issues with your website.

Replying to sibeguy:

I wonder if the 5.3.3 made some database configuration change.

5.5.3 had a db-related change which runs when no site is installed (i.e. fresh install). The problem reported in this ticket is for an update of an existing site.

In reviewing with the Release Team, it does not seem to be from the 5.5.3 WordPress core software update itself.

We recommend trying the support forums to get help with your site: ​https://wordpress.org/support/forums/.

[sibeguy]

This issue has been resolved. It had something to do with MySQL server. I haven't gotten the details from my hosting support so can't post what was done. I will say the only thing that happened between the sites working and them not was the install of 5.5.3. It may have left the MySQL server in a dysfunctional state.