Update: after leaving my laptop and back again several minutes, the error message is gone and I see the main dashboard.
Looking to the console, there was a 15 minutes gap, then I saw some errors on the console:
16:19:22 web.1 | * Restarting with inotify reloader
16:19:23 web.1 | * Debugger is active!
16:19:23 web.1 | * Debugger PIN: 302-015-712
--- idle ---
16:34:42 web.1 | 127.0.0.1 - - [31/May/2018 16:34:42] "POST / HTTP/1.1" 200 -
16:34:45 web.1 | 127.0.0.1 - - [31/May/2018 16:34:45] "GET /robots.txt HTTP/1.1" 200 -
16:34:46 web.1 | 127.0.0.1 - - [31/May/2018 16:34:46] "GET /api/method/frappe.async.get_user_info?sid=2d7227b05c9a7a4ed19354dfe1a53d6369e60a8088c08c1d8f3bb927 HTTP/1.1" 200 -
16:34:54 web.1 | 127.0.0.1 - - [31/May/2018 16:34:54] "GET /desk HTTP/1.1" 200 -
16:34:54 web.1 | 127.0.0.1 - - [31/May/2018 16:34:54] "GET /assets/js/control.min.js?ver=1527773796.0 HTTP/1.1" 200 -
16:34:54 web.1 | 127.0.0.1 - - [31/May/2018 16:34:54] "GET /assets/js/report.min.js?ver=1527773796.0 HTTP/1.1" 200 -
16:34:54 web.1 | Error on request:
16:34:54 web.1 | Traceback (most recent call last):
16:34:54 web.1 | File "/home/yyy/frappe-bench/env/lib/python2.7/site-packages/werkzeug/serving.py", line 270, in run_wsgi
16:34:54 web.1 | execute(self.server.app)
16:34:54 web.1 | File "/home/yyy/frappe-bench/env/lib/python2.7/site-packages/werkzeug/serving.py", line 261, in execute
16:34:54 web.1 | write(data)
16:34:54 web.1 | File "/home/yyy/frappe-bench/env/lib/python2.7/site-packages/werkzeug/serving.py", line 227, in write
16:34:54 web.1 | self.send_header(key, value)
16:34:54 web.1 | File "/usr/lib/python2.7/BaseHTTPServer.py", line 412, in send_header
16:34:54 web.1 | self.wfile.write("%s: %s\r\n" % (keyword, value))
16:34:54 web.1 | IOError: [Errno 32] Broken pipe
...
16:34:57 web.1 | ----------------------------------------
16:34:57 web.1 | Exception happened during processing of request from ('127.0.0.1', 37792)
16:34:57 web.1 | Unhandled exception in thread started by <bound method Thread.__bootstrap of <Thread(Thread-31, stopped daemon 139775498512128)>>
16:34:57 web.1 | Traceback (most recent call last):
16:34:57 web.1 | File "/usr/lib/python2.7/threading.py", line 774, in __bootstrap
16:34:57 web.1 | ----------------------------------------
16:34:57 web.1 | Exception happened during processing of request from ('127.0.0.1', 37762)
16:34:57 web.1 | Unhandled exception in thread started by <bound method Thread.__bootstrap of <Thread(Thread-28, stopped daemon 139776036411136)>>
16:34:57 web.1 | Traceback (most recent call last):
16:34:57 web.1 | File "/usr/lib/python2.7/threading.py", line 774, in __bootstrap
16:34:57 web.1 | self.__bootstrap_inner()
16:34:57 web.1 | File "/usr/lib/python2.7/threading.py", line 814, in __bootstrap_inner
16:34:57 web.1 | (self.name, _format_exc()))
16:34:57 web.1 | File "/usr/lib/python2.7/traceback.py", line 241, in format_exc
16:34:57 web.1 | etype, value, tb = sys.exc_info()
16:34:57 web.1 | AttributeError: 'NoneType' object has no attribute 'exc_info'
I had the same issue - new installation of bench, frappe(develop) and erpnext(develop), running in development. Tried bench --site site1.local reinstall, no difference. Nothing unusual in the bench terminal output.
Tried going back in the options and changing language from ‘English (United Kingdom)’ to ‘English’ - success first time. Possibly a coincidence, possibly not? I did also run ‘bench config http_timeout 6000’ though.
This was my experience too… It wasn’t working until it was. Very confusing! Definitely more than 3 times clicking retry for me. But now it is up and we are evaluating it to see if we want to switch (from Odoo 9)!
I think it’s because the werkzeug WSGI server reloaded when the python source code altered/updated hence the existing http connection will close too (broken pipe). The benefit of autoreload is we don’t have to restart the server/bench when we update the python source code.
in completing setup, several processes (and data writing) need to be done.
somehow in the middle, the process can take too long a time, or simply just got broken.
so the process stop and notify as failed.
when retrying, the process starts over, but since the previous process has done (or the data has been written), those process just ignored (or bypassed). And the process continue with the next.
do this retry several times, and finally the whole process (and data) is completed.
now you get that: “…and finally it works” which actually (maybe) it does work from the beginning but the process que just gets in the way.
I don’t know what happen behind the screen, but that is just my observation. So maybe the “updates” need to handle those queing process?
Exactly it’s work after 10 retry retry…;
I found on the logs that issues where detected on the modification of *.cpython-35.pyc, where * is any module; And after retry, the file is not the same…As @rahy said it seems like the retry correct the file…
Thanks to all