Odoo 11 blank page in Back-end - odoo
The Problem
In the Odoo Back-end, sometime, the window will only display the menuitems, the rest of the screen stay blank.
Clicking on any of this menu will change the url to https://my_server_ip/web?debug#menu_id=68&action=
The only thing that will change is the menu_id's value, but the action's value will stay empty.
At first it was thinking it was when refreshing a page I was already on. But I can't reproduce the bug consistently (Once it happenned it reproduce every time, but if I clear cache/cookies, which solve the problem for a small time, the problem will reproduce at some point, but I can't find a behaviour to reproduce it when I want. It will just happen at some random point). It just happen after a while, sometimes hour of usage later, sometime two pages loading later. Sometime, no problem for a day, but the tomorrow at first try, bug happen again.
Tried solutions
Here are the relevent solution tried :
Clear cache and cookies.
Restart server
Removing all the entry of ir_attachment which contain web/content. (As recommanded on Odoo git issues).
Creating a new VM from scratch, with no relation to the bugged Odoo VM, install Postgres and Odoo on this new VM. Then proceed to reinstall all the modules that were installed.
Impact of above solutions
In the same order :
Problem solved, but happens again a few time later.
Usually does not work by itself, but sometime did.
I think it worked after doing this and rebooting server, but can't reproduce the bug to test it again right now. When bug show up again, I'll try and edit to confirm that this work.
The machine behaviour is the same. At first it worked, but after a while, the bug started again.
Configuration
Version Odoo : Odoo 11.0-20190108 (Community Edition)
OS : Debian stretch
Community modules installed :
backend_theme_v11
base_location
base_location_geonames_import
send_sms
web_responsive
Custom module developped internally for this mission are also installed.
VM installed on a Proxmox
Nginx service
Content of odoo.conf
; This is the password that allows database operations:
; admin_passwd = [admin_password]
db_host = False
db_port = False
db_user = odoo
db_password = [db_password]
addons_path = /usr/lib/python3/dist-packages/odoo/addons,/opt/odoo/modules
limit_memory_hard = 1677721600
limit_memory_soft = 629145600
limit_request = 8192
limit_time_cpu = 600
limit_time_real = 1200
max_cron_threads = 1
workers = 5
# HTTP CONFIG
proxy_mode = True
xmlrpc = True
xmlrpc_interface = 127.0.0.1
netrpc_interface = 127.0.0.1
Https Deployment and longpolling deployment
This documentation was followed to do the Https and longpolling deployment
Log
Logs produced on Odoo when the bug occurs
2019-01-10 09:56:01,883 17076 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:01] "GET /web HTTP/1.0" 200 -2019-01-10 09:56:02,262 17076 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "GET /web/image/ir.ui.menu/98/web_icon_data HTTP/1.0" 304 -
2019-01-10 09:56:02,294 17076 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "GET /web/image/ir.ui.menu/103/web_icon_data HTTP/1.0" 304 -
2019-01-10 09:56:02,327 17076 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "GET /web/image/ir.ui.menu/155/web_icon_data HTTP/1.0" 304 -
2019-01-10 09:56:02,360 17076 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "GET /web/image/ir.ui.menu/68/web_icon_data HTTP/1.0" 304 -
2019-01-10 09:56:02,465 17076 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "GET /web/image/ir.ui.menu/109/web_icon_data HTTP/1.0" 304 -
2019-01-10 09:56:02,523 17076 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "GET /web/image/ir.ui.menu/133/web_icon_data HTTP/1.0" 304 -
2019-01-10 09:56:02,545 17075 INFO Developpement odoo.modules.registry: Invalidating all model caches after database signaling.
2019-01-10 09:56:02,559 17075 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "GET /web/image/ir.ui.menu/142/web_icon_data HTTP/1.0" 304 -
2019-01-10 09:56:02,595 17075 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "GET /web/image/ir.ui.menu/140/web_icon_data HTTP/1.0" 304 -
2019-01-10 09:56:02,616 17073 INFO Developpement odoo.modules.registry: Invalidating all model caches after database signaling.
2019-01-10 09:56:02,631 17073 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "GET /web/image/ir.ui.menu/144/web_icon_data HTTP/1.0" 304 -
2019-01-10 09:56:02,653 17077 INFO Developpement odoo.modules.registry: Invalidating all model caches after database signaling.
2019-01-10 09:56:02,668 17077 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "GET /web/image/ir.ui.menu/129/web_icon_data HTTP/1.0" 200 -
2019-01-10 09:56:02,693 17074 INFO Developpement odoo.modules.registry: Invalidating all model caches after database signaling.
2019-01-10 09:56:02,710 17075 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "GET /web/webclient/qweb?mods=web,base,bus,web_tour,mail,sales_team,calendar,web_planner,contacts,crm,note,custom_module1,auth_signup,web_responsive,backend_theme_v11,base_import,base_location,base_location_geonames_import,iap,send_sms,sms,web_diagram,web_editor,web_kanban_gauge,web_settings_dashboard,portal HTTP/1.0" 304 -
2019-01-10 09:56:02,713 17074 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "GET /web/image/ir.ui.menu/5/web_icon_data HTTP/1.0" 304 -
2019-01-10 09:56:02,715 17076 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "POST /web/dataset/call_kw/res.users/read HTTP/1.0" 200 -
2019-01-10 09:56:02,747 17077 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "GET /web/image/ir.ui.menu/4/web_icon_data HTTP/1.0" 200 -
2019-01-10 09:56:02,762 17073 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "POST /web/dataset/call HTTP/1.0" 200 -
2019-01-10 09:56:02,767 17077 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:02] "GET /dashboard HTTP/1.0" 200 -
2019-01-10 09:56:03,059 17077 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:03] "POST /web/webclient/translations HTTP/1.0" 200 -
2019-01-10 09:56:03,115 17077 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:03] "GET /web/webclient/locale/fr_FR HTTP/1.0" 200 -
2019-01-10 09:56:03,218 17077 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:03] "POST /mail/client_action HTTP/1.0" 200 -
2019-01-10 09:56:03,253 17076 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:03] "POST /web/dataset/call_kw/res.users/read HTTP/1.0" 200 -
2019-01-10 09:56:03,265 17078 INFO Developpement odoo.modules.registry: Invalidating all model caches after database signaling.
2019-01-10 09:56:03,279 17076 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:03] "POST /calendar/notify HTTP/1.0" 200 -
2019-01-10 09:56:03,302 17073 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:03] "GET /web/image?model=res.users&field=image_small&id=1 HTTP/1.0" 304 -
2019-01-10 09:56:03,316 17077 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:03] "POST /web/action/load HTTP/1.0" 200 -
2019-01-10 09:56:03,391 17075 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:03] "POST /web/dataset/call_kw/web.planner/search_read HTTP/1.0" 200 -
2019-01-10 09:56:03,409 17074 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:03] "POST /web/dataset/call_kw/res.users/activity_user_count HTTP/1.0" 200 -
2019-01-10 09:56:03,439 17076 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:03] "POST /web/dataset/call_kw/mail.message/load_views HTTP/1.0" 200 -
2019-01-10 09:56:03,519 17074 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:03] "POST /web/dataset/call_kw/ir.filters/get_filters HTTP/1.0" 200 -
2019-01-10 09:56:03,575 17074 INFO Developpement werkzeug: 127.0.0.1 - - [10/Jan/2019 09:56:03] "POST /web/dataset/call_kw/mail.message/message_fetch HTTP/1.0" 200 -
*Logs produced on the nginx service that we don't know if is related to the bug
2019/01/10 11:52:37 [error] 165#165: *10008 upstream prematurely closed connection while reading response header from upstream, client: 82.127.91.106, server: [server_url], request: "POST /longpolling/poll HTTP/1.1", upstream: "http://127.0.0.1:8072/longpolling/poll", host: "[server_url]", referrer: "https://[server_url]/web?debug"
NOTES :
This line only contains one of my four custom module, and I don't know if it's normal.
[10/Jan/2019 09:56:02] "GET /web/webclient/qweb?mods=web,base,bus,web_tour,mail,sales_team,calendar,web_planner,contacts,crm,note,custom_module1,auth_signup,web_responsive,backend_theme_v11,base_import,base_location,base_location_geonames_import,iap,send_sms,sms,web_diagram,web_editor,web_kanban_gauge,web_settings_dashboard,portal HTTP/1.0" 304 -
Also note the 304 errors. I can't find any explaination for that on a Odoo installed on a Debian environment.
Related additional bugs
In top of this problem, thoses one might also occur on the same server
Menuitem pictures not getting loaded (happens more often than the blank page)
Redirection on the login page not beeing automatic, "You should be redirected in a few second, if not click here .../web/login". Used to be systematic, but now don't seems to occur anymore.
Solutions not applicable for this case
This might help you if you found this question after a research, but doesn't apply to the spec of this question
On windows installation, a module exist to solve this : web_fix_blank_page.
This exist only for V10 at the time this question is written and only fix OS related problem for Odoo, causing the blank page error.
Final Word
Since the 4 tried solutions did not work, and I tried two version of the nighlty-built odoo, 3 months appart, I expect the problem to come from my custom modules. But it's thousands and thousands of LOC.
What could cause this, and how can I find the cause in all thoses files.
May it be something else? What could it be?
I can't uninstall my module one by one to try to find in which module the error is, at least not for all. For two reason :
Some modules depends of others, so I can't just try the child module without the parent.
The bug is non reproductible at will, it will just happen at some point and I can't be sure wether the bug is, or is not in a module I uninstalled with confidence.
EDIT : New informations
It seems like the bug occurs only when a request to the custom controllers (and /web/session/authenticate) are made.
If after a request, I try to refresh a page in the navigator, the described error occurs. And the error is fixed by clearing the cache. Once the cache is cleared, refreshing still produce the error. Once I restart the server and clean the cache, no problem occurs.
If I make a request, restart the server then refresh, no error, without cleaning the cache.
I found what was causing this. 5 months and still no answer so I'll post my answer here.
This answer will probably help you if you have custom routes in your controllers.
First of all, the solution
You should never redefine any attribute of the Response object in a direct manner.
This mean that a line such as Response.status = '400 Invalid credentials' will cause this error to occur everytime the route in which you have it is called.
More in-depth about this bug :
When you do Response.status = '400 Bad request' you regain control of the Response object, and interrupt the normal workflow of odoo. Therefore, it is no longer able to use it correctly, and every Response returned by any odoo route will have the last status defined until you restart server (in this exemple, 400, so every request is considered as a BadRequest, causing the blank page and diverses others bugs, but 200 would do the same since 302 is necessary for redirections).
If anybody knows why Odoo doesn't regain control of the Response object, feel free to edit this answer (and please do, this bugged me for so long).
So how to modify the response status? :
A quick glance at the core modules gives us the answer
Case of custom HTTP method (Like POST) :
raise werkzeug.exception.BadRequest("400 Invalid credentials")
Note that you can't raise any other error than 400 by default. If you want to do so, you have to modify the http.py file in the odoo's root repertory. But be aware that this probably mean you didn't understood the HTTP protocol, as I did. In fact, most of the time you should return 200, there is no HTTP error so request is a success. However you should add a error attribute to the json returned if behavior is not what the client expect (like a wrong password at connexion).
Case of standard method AFAIK (Like GET):
response = werkzeug.wrappers.Response(json.dumps({<i>[your json dictionary]</i>}), status="400 Invalid credentials")
return response
Related
Unknown behavior in Apache HTTPD
Yesterday we faced a strange behavior when reading access log of Apache httpd. An example of below: 207.46.13.135 - - [25/Sep/2022:15:28:28 +0700] "GET / HTTP/1.1" 302 287 (core.c/0/translate_name) - 140 This is a normal access entry: x.x.x.x - - [26/Sep/2022:14:16:57 +0700] "GET /corp/L003/consumer/theme/vn.ssc.css HTTP/1.1" 200 1043 (core.c/0/handler) - 830 We have directives to proxy and redirect the request going to the system. But why this does not redirect (the return code 302 is understandable when in debug mod but why we don't get it when having in production log) – > We suspected that these IPs used some kind of engines to flood the web server, only to response status but not the content.
Fail2ban filter for a specific string in *access.log
I have many GET Request on my server to "nike-air" URLs like this 216.*.*.* - - [13/Dec/2016:20:07:54 +0100] "GET /jd/nike-huarache-2010.php HTTP/1.1" 404 216.*.*.* - - [13/Dec/2016:20:07:57 +0100] "GET /jd/nike-roshe-run-homme-original.php HTTP/1.1" 404 187.*.*.* - - [13/Dec/2016:20:17:26 +0100] "GET /jd/nike-mercurial.php HTTP/1.1" 404 I decide to create a fail2ban filter for stop it: # apache-nike.conf [Definition] failregex = ^<HOST> -.*"GET .*nike-.*".* ignoreregex = It works but I think it can be improved? Too bad there is no online tool to create filters :) Thank you for your suggestions.
PUT forbidden in SVN
I have set up SVN 1.8.8 with Apache on RedHat running on AWS. I am committing my first base code now and pushing all my current baselines into /tags. Everything seems good, until I come to .rar files. The commit is failing with the following error message. I've tried to debug it for 2 days now. Ensured that my repositories are owned by 'apache' user There is no Deny directive in /etc/httpd/conf/httpd.conf and /etc/httpd/conf.d/subversion.conf Added AddType for .rar Log shows that the PUT is via serf Some may ask why am I committing a zipped file instead of the individual files. Well, this particular .rar is an incoming deliverable and I would want to track it as an entire package, on top of the individual files that I am developing myself. It is happening only to this file extension. Can anyone help? Update 20140605: I tried using CLI and force it to serf, same error. Also, here is a snapshot of apache httpd's access_log. 192.101.84.225 - - [05/Jun/2014:05:34:13 +0000] "OPTIONS /svn/test/trunk HTTP/1.1" 401 517 "-" "SVN/1.8.9 (x64-microsoft-windows) serf/1.3.5 TortoiseSVN-1.8.7.25475" 192.101.84.225 - tanst [05/Jun/2014:05:34:13 +0000] "OPTIONS /svn/test/trunk HTTP/1.1" 200 188 "-" "SVN/1.8.9 (x64-microsoft-windows) serf/1.3.5 TortoiseSVN-1.8.7.25475" 192.101.84.225 - tanst [05/Jun/2014:05:34:13 +0000] "OPTIONS /svn/test/trunk HTTP/1.1" 200 97 "-" "SVN/1.8.9 (x64-microsoft-windows) serf/1.3.5 TortoiseSVN-1.8.7.25475" 192.101.84.225 - tanst [05/Jun/2014:05:34:14 +0000] "POST /svn/test/!svn/me HTTP/1.1" 201 - "-" "SVN/1.8.9 (x64-microsoft-windows) serf/1.3.5 TortoiseSVN-1.8.7.25475" 192.101.84.225 - tanst [05/Jun/2014:05:34:14 +0000] "HEAD /svn/test/trunk/testing.rar HTTP/1.1" 404 - "-" "SVN/1.8.9 (x64-microsoft-windows) serf/1.3.5 TortoiseSVN-1.8.7.25475" 192.101.84.225 - tanst [05/Jun/2014:05:34:15 +0000] "DELETE /svn/test/!svn/txn/1-k HTTP/1.1" 204 - "-" "SVN/1.8.9 (x64-microsoft-windows) serf/1.3.5 TortoiseSVN-1.8.7.25475" There are no errors in error_log.
Can't understand these lines in apache log file
I get lines like these 101.102.2.137 - - [13/Sep/2013:15:20:53 +0300] "\xda\x85^iK\x94bUt\xb2DR\x12l\x19\x11\x06\xd0\x86\x88\xf43\x0c\x14e\x17\xab\xf8SUGF{L\xb0T\x91\x12\xeb\xce\xdc\x1e\x19NS\xc6+\x82;c\r\x96\xd7#\xfb\x01n" 400 226 46.47.127.146 - - [13/Sep/2013:15:23:00 +0300] "-" 408 - 92.163.103.246 - - [13/Sep/2013:15:27:23 +0300] "-" 408 - 124.84.210.50 - - [13/Sep/2013:15:59:56 +0300] "\x9e\x89\xd6" 200 4487 in my apache log and i don't know what do they mean. I use WAMP just to test stuff i don't know how can anyone get my IP to connect. Can you tell me what the lines mean?
Apache access log : multiple status code
In Apache access.log, I am used to this kind of access log line: 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 I was checking some apache access logs this morning and found something I'm not used to: 192.168.1.10- - [20/Feb/2013:00:00:45 +0000] "POST /form/... 404 200 252 "-" "-" 435835 There are multiple status code. Does-it mean the request was sended multiple times (something like a failed/retry mechanism?