Univention Bugzilla – Bug 31505
cherrypy.TimeoutError
Last modified: 2016-10-10 17:15:48 CEST
If generating reports for many users for exmaple after a certain amount of time (5 minutes) an internal apache timeout is reached and you get an error message in the umc (502). The backend process keeps generating the report until it is complete (you can get it from "/var/www/univention-directory-reports"), but the user doesn't get any response at the frontend. If raising the timeout in apache2.conf (Timeout) the frontend process keeps working for longer (about 9 minutes) and then a traceback is generated: " Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/cherrypy/_cpwsgi.py", line 79, in setapp s, h, b = self.get_response() File "/usr/lib/pymodules/python2.6/cherrypy/_cpwsgi.py", line 219, in get_response response = self.request.run(meth, path, qs, rproto, headers, rfile) File "/usr/lib/pymodules/python2.6/cherrypy/_cprequest.py", line 567, in run raise cherrypy.TimeoutError() TimeoutError " This time it seems that cherrypy itself reaches a timeout. I've already tried to configure this parameter via: " def run_cherrypy(): # TODO FIXME Folgenden Configeintrag einbauen, wenn loglevel in (0,1,2) # 'server.environment': 'production', cherrypy.config.update( { 'server.socket_port': int( configRegistry.get( 'umc/http/port', 8090 ) ), 'server.socket_host': configRegistry.get( 'umc/http/interface', '127.0.0.1' ), 'server.request_queue_size' : 100, 'engine.autoreload_on': False, ++ 'tools.sessions.timeout': 20, 'tools.response_headers.on': True, " Unfortunately this doesn't help. As the report is only reachable via net if the file itself is directly addressed as url, this is no "nice" workaround because you have to determine the filename before.
Good catch. I think we have some more timeout issues in this area, see also Bug #24852. Can we simple increase the timeout?
(In reply to comment #1) > Good catch. > > I think we have some more timeout issues in this area, see also Bug #24852. Can > we simple increase the timeout? Another example is Bug 25465. Increasing the timeout does not solve the root of the problem. Ideally, we would need a sort of progress handling for calls that may take more time than a few seconds.
We received a feedback containing the same cherrypy.TimeoutError traceback with remark [#2014051921008964]: Beim Aufruf der App-Verwaltung aufgetreten.
(In reply to Florian Best from comment #3) > We received a feedback containing the same cherrypy.TimeoutError traceback > with remark [#2014051921008964]: > Beim Aufruf der App-Verwaltung aufgetreten. We received it 3 times from different mail addresses. Another Remark: app center lässt sich nicht aufrufen (In reply to Alexander Kläser from comment #2) > (In reply to comment #1) > > Good catch. > > > > I think we have some more timeout issues in this area, see also Bug #24852. Can > > we simple increase the timeout? > > Another example is Bug 25465. Increasing the timeout does not solve the root > of the problem. Ideally, we would need a sort of progress handling for calls > that may take more time than a few seconds. Yes, IMHO we should not have commands which aren't answered immediately (thats also against HTTP design).
Reported by: 3.2-3 errata181 (Borgfeld) Remark: SBS2003 + UCS Server Reported by: 3.2-3 errata182 (Borgfeld) Remark: Active Directory-Verbindung SBS2003 Windows 2000 Modus
We received the following traceback: UCS Version: undefined Unrecoverable error in the server. TimeoutError raise cherrypy.TimeoutError() File "/usr/lib/pymodules/python2.6/cherrypy/_cprequest.py", line 567, in run response = self.request.run(meth, path, qs, rproto, headers, rfile) File "/usr/lib/pymodules/python2.6/cherrypy/_cpwsgi.py", line 219, in get_response s, h, b = self.get_response() File "/usr/lib/pymodules/python2.6/cherrypy/_cpwsgi.py", line 79, in setapp Traceback (most recent call last): Unrecoverable error in the server.
last traceback reported again (UCS 3.2)
Reported again, 3.2-6 errata376 (Borgfeld)
This issue has been filed against UCS 3.1. UCS 3.1 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please reopen this bug. In this case please provide detailed information on how this issue is affecting you.