INTERNAL SERVER ERROR, Your system is being updated. Please refresh again after a few moments, Verifying

Mukane_Onesimas · August 21, 2019, 5:01am

I have 4 sites running on different ports when i did a bench update --reset

the errors in the pictures were reflected.
I have been solving the errors but currently they have refused. need help.
bench update brings the same error, bench migrate the same
Thanks

Iulian_Olaru · August 21, 2019, 6:18am

I had a similar situation once before and I fixed it by restarting supervisor. Often restarting supervisor fixes some weird happenings … at least for me.

lasalesi · August 21, 2019, 6:34am

Which Frappe/ERPNext version are you running on? In case it is v11 or later, switching Python to v3 might help…

Mukane_Onesimas · August 21, 2019, 6:35am

let me trying switching

Mukane_Onesimas · August 21, 2019, 6:36am

Kindly send me instructions of switching python to v3

lasalesi · August 21, 2019, 6:37am

In order to switch the Python environment, do the following:

$ sudo apt install python3-dev
$ bench migrate-env python3
$ bench update

vrms · August 21, 2019, 6:51am

I had the same “Your system is being updated” situaton after updating to v12.

changing the value for maintenance mode to 0 in

~/frappe-bench/sites/common_site_config.json

… solved it for me.

(don’t expect any explanation why this was set to 1 and when)

Mukane_Onesimas · August 25, 2019, 2:45pm

Dear Team,
I have sat down with my team and done complete trouble shooting for all the above problems, we found a number of issues that cause them and we solved them one by one. Internal server error, system updating in some cases may not be solved by simply going to the config file. My team has found out many issues that may cause it and are documenting every solution step by step. Kindly be patient for us to be able to finish this document and we shall share the solution. we tried to search but the solutions didn’t work hence we sat down and solved it.

Thanks
Mukane Onesimas

clarkej · August 26, 2019, 1:32pm

Good catch @vrms

“changing the value for maintenance mode to 0 in”

To do that, do this:

bench --site site-name set-maintenance-mode off

FWIW searches for these below did not shed light on what this command line switch does

frappe@ubuntu:~/frappe-bench$ find . -name ‘.py’ | xargs grep maintenance_mode
frappe@ubuntu:~/frappe-bench$ find . -name '.py’ | xargs grep set-maintenance-mode

github.com

frappe/frappe/blob/develop/frappe/commands/scheduler.py#L99


      
          	output = {
          		"text": "Scheduler is {status} for site {site}",
          		"json": '{{"status": "{status}", "site": "{site}"}}',
          	}
          
          	with frappe.init_site(site=site):
          		match state:
          			case "status":
          				frappe.connect()
          				status = "disabled" if is_scheduler_inactive(verbose=verbose) else "enabled"
          				return print(output[format].format(status=status, site=site))
          			case "pause" | "resume":
          				from frappe.installer import update_site_config
          
          				update_site_config("pause_scheduler", state == "pause")
          			case "enable" | "disable":
          				frappe.connect()
          				toggle_scheduler(state == "enable")
          				frappe.db.commit()
          
          		print(output[format].format(status=f"{state}d", site=site))

vrms · August 26, 2019, 6:12pm

plaid around with that a bit and this works pretty well

… just to whom this is of any interest, the command mentioned corresponds with ~/frappe-bench/sites/[site_name]/site_config.json, not the common_site_config.json mentioned earlier.

szufisher · September 23, 2019, 5:02am

solved my problem which may caused by switch from python 2 to python 3 at system level, then after that apt-get update/ upgrade, anyway, many thanks.

casesolved-co-uk · June 1, 2020, 3:04am

For reference I’ve just been scratching my head over a similar problem (see screenshot).

I ran bench migrate by accident and it failed halfway through. I set maintenance_mode to zero and no change.

It turns out the patch handler also blocks access in the database while doing a migration, but doesn’t clear it until the migration finishes.
You can test with:

bench console
import frappe

Set using:
frappe.modules.patch_handler.block_user(True)
Clear using:
frappe.modules.patch_handler.block_user(False)

To check the database to see if it is set:

bench mariadb
select defkey,defvalue from `tabDefaultValue` where parent like '__global' and defkey like '__session_status%';

When set:

+--------------------------+--------------------------------------------------------------------------------------------------------------+
| defkey                   | defvalue                                                                                                     |
+--------------------------+--------------------------------------------------------------------------------------------------------------+
| __session_status         | stop                                                                                                         |
| __session_status_message | Patches are being executed in the system. Please try again in a few moments.                                 |
+--------------------------+--------------------------------------------------------------------------------------------------------------+

HTH!

Sirjames · June 14, 2020, 5:31pm

@Mukane_Onesimas
Your offer to document how you resolved this is amazing. Waiting patiently as you have advised sir.

pioneerpathan · December 29, 2020, 5:48am

Hi @vrms. It worked for me as well. Thanks.

casesolved-co-uk · February 10, 2022, 11:46pm

Just found you may need to do the following to avoid an AttributeError:

bench --site <name> console
from frappe.modules.patch_handler import block_user
block_user(True)
block_user(False)

I assume something changed in python at some point…