Setup failed Could not start up: Failed to complete setup

Frappe Framework Bug
1

Trying to use a simple manual setup on a freshly initialized bench with frappe, erpnext, hrms apps. The installation seemed to go through just fine.

The only lines which looked strange are these ones:

Patching Existing Data...
rename_field: kra_title not found in table for: Appraisal Template
rename_field: kra_template not found in table for: Appraisal
Thank you for installing Frappe HR!
Updating Dashboard for hrms

These lines don’t tell if the “not found in table” items are a problem or not, so maybe they are a success message, that it’s good they are not found? Who knows.
Anyway, the ‘Thank you for installing Frappe HR!’ looks like a success, although technically that’s only implicit.

Now going through the first use setup wizard, with no special inputs really, I can’t access the Chart of Accounts:

Method Not Allowed
You are not permitted to access this resource.

What?
Am I not the Administrator of the install?
How can anything be refused to me at this point?

Opening the error details clicking on the little triangle gives:

Function **erpnext.accounts.utils.get_coa** is not whitelisted.

What? API access not allowed in the setup wizard?

The CoA is under this message and shows the root node of the CoA, but clicking it or trying to expand all yields a similar error message:

Method Not Allowed
You are not permitted to access this resource.Function **frappe.desk.treeview.get_all_nodes** is not whitelisted.

Ignoring this problem, clicking “Complete Setup” yields:

#### Method Not Allowed
You are not permitted to access this resource.
Function **frappe.desk.page.setup_wizard.setup_wizard.setup_complete** is not whitelisted.

It’s a fresh version-15 setup, pulled from github just now:

$ bench version
erpnext 15.12.2
frappe 15.13.0
hrms 15.11.0

$ bench --version
5.22.0

$ cat /etc/os-release
PRETTY_NAME=“Ubuntu 22.04.3 LTS”

Well, what now?
Stuck right at the start in a manual vanilla install.

2

After a reboot, it seems to work as expected.
(I don’t know if this counts as a solution.)

So my installation work in itself was fine.
Although I still would like to know how this happened.
Is a reboot a recommended step before starting to use such a setup?

Now the setup wizard ran normally, I could examine the different CoAs, and after it finished doing its setup stuff, there is running installation, even including the demo data as selected.

Nice!

3

The problem “kind of” reappeared, which allows me now to have an educated guess as to the reason of the original problem.

I’m using several benches on the same server on which I create sites having the same name, but different ports (“bench new-site” creates new port numbers automatically). This allows me to not have to edit the hosts file on every accessing station on the LAN (or fiddle with DHCP configuration) each time I add another bench + site. I can just use the same URL and just access :8001 instead of :8000 or :8002. This allows me to switch easily between versions or language sites.

But the problem is that they interfere with each other anyway. For instance, once I access a site at :8002, it throws me out of the others. This is unexpected and annoying, because you need to re-login at the other sites each time you pass from one to another.

I’m not sure about the cause, but I suspect that the access logic just checks for IP and not IP:PORT, as it probably should.
So In a way, switching to sites on other ports of the same IP acts as a DoS on the site with the port used before.

And that’s probably what happened during the setup:
There was indeed another site running when I set up the new one, and that other site’s frontend logic (in the browser) probably did some access to it’s backend, and this disabled the access to the new site configured for the same IP (but another port).
That other site got disabled (because it ran on a manual bench start) during the reboot, and until I restarted it, the new site ran nicely and comfortably. Once restarted, the new site got DoS’ed, needing re-logins, as well as the old one.

The problem is that, the frontends talking to the backends all the time, even if you don’t do anything on the User Interface, the site you are accessing will become rapidly DoS’ed by the others. You can use it a short while though, but get thrown out often.

I don’t know if this is expected behavior, but I do consider this faulty, because it disallows a useful use-case for no good reason – at least I didn’t figure it out, if it exists; it might as well be a relict good enough for some common use cases, but not for these ones.

(The “Allow only one user session per user” is not marked in any site, they are independent from each other anyway as they run on their own benches.)

The URL definition includes the port.

So why not include the (destination) port in the authorization logic (of the frontend, probably)? That would be the solution to this problem and allow different bench servers on the same domain name and IP to be used in parallel.

Or am I missing something else?