#21773 closed Bug (fixed)

development server sometimes takes a long time to restart after source has been changed

Reported by: clime Owned by: mardini
Component: Core (Management commands) Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

There are cases when development server takes a long time to restart after sources have been changed. It happens when an exception has been raised. I fix the exception and refresh the page but it keeps throwing the same error. I usually kill the server with ctrl-c to restart it manually. But then comes another problem when I try to start it, that is: "Error: That port is already in use." Django server does not release the port when being killed. Would it be possible to release it so I can start it immediately?

Change History (12)

comment:1 Changed 18 months ago by clime

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

One additional note, after ctrl-c, some thread of the server probably keeps running for some time because later I get a message about keyboard interrupt in the console. So that is probably the reason the port is not immediately available in such situations.

Last edited 18 months ago by clime (previous) (diff)

comment:2 Changed 18 months ago by mjtamlyn

  • Triage Stage changed from Unreviewed to Accepted

I do occasionally see this behaviour. I have no idea what causes it. The thread continuing to run in the background is very annoying and normally I have to resort to kill

comment:3 Changed 18 months ago by aaugustin

Yes, I've seen that too. Last time I hit this problem, I had an infinite loop in a view.

comment:4 follow-up: Changed 18 months ago by claudep

It would be useful to know on which platform(s) and which exact Django version that behavior arises, as the reload method might be different.

comment:5 in reply to: ↑ 4 Changed 17 months ago by clime

Replying to claudep:

It would be useful to know on which platform(s) and which exact Django version that behavior arises, as the reload method might be different.

The first version of Django I have used was 1.4 and I think I have been hitting this issue since beginning. I am totally sure that it is in 1.5 and 1.6.

The platform is linux/fedora. By the way I have just encountered this issue again. This exception was raised:

Environment:


Request Method: GET
Request URL: http://127.0.0.1:8008/messagethreads/

Django Version: 1.6.1
Python Version: 2.7.3
Installed Applications:
('django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.messages',
 'django.contrib.staticfiles',
 'south',
 'grappelli',
 'django.contrib.admin',
 'django.contrib.admindocs',
 'endless_pagination',
 'debug_toolbar',
 'djangoratings',
 'imagekit',
 'watson',
 'web')
Installed Middleware:
('django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'middleware.UserMemberMiddleware',
 'middleware.ProfilerMiddleware',
 'middleware.VaryOnAcceptMiddleware',
 'debug_toolbar.middleware.DebugToolbarMiddleware',
 'watson.middleware.SearchContextMiddleware')


Traceback:
File "/srv/www/envs/cb/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response
  107.                     response = middleware_method(request, callback, callback_args, callback_kwargs)
File "/srv/www/envs/cb/lib/python2.7/site-packages/debug_toolbar/middleware.py" in process_view
  73.             response = panel.process_view(request, view_func, view_args, view_kwargs)
File "/srv/www/envs/cb/lib/python2.7/site-packages/debug_toolbar/panels/profiling.py" in process_view
  133.         return self.profiler.runcall(view_func, *args, **view_kwargs)
File "/usr/lib64/python2.7/cProfile.py" in runcall
  149.             return func(*args, **kw)
File "/srv/www/envs/cb/lib/python2.7/site-packages/django/contrib/auth/decorators.py" in _wrapped_view
  22.                 return view_func(request, *args, **kwargs)
File "/srv/www/cb/web/views.py" in messagethread_list
  1176.         'model_tag': MessageThread.tag,

Exception Type: NameError at /messagethreads/
Exception Value: global name 'model_tag' is not defined

I fixed it and then tried to refresh the page repeatedly. Nevertheless, I was still getting the same exeption. In the end, I lost patience and decided to restart the server (the usual scenario). After killing it by ctrl-c, I tried to restart it:

^C(cb)clime@den /srv/www/cb ./manage.py runserver 127.0.0.1:8008
Validating models...

0 errors found
January 27, 2014 - 18:49:35
Django version 1.6.1, using settings 'cb.settings'
Starting development server at http://127.0.0.1:8008/
Quit the server with CONTROL-C.
Error: That port is already in use.
(cb)clime@den /srv/www/cb $ Exception KeyboardInterrupt in <module 'threading' from '/usr/lib64/python2.7/threading.pyc'> ignored

The KeyboardInterrupt exception appeared around 10 secs later. Then I could finally start the server again.

comment:6 Changed 15 months ago by timo

  • Component changed from Uncategorized to Core (Management commands)

comment:7 Changed 14 months ago by mardini

It's probably not a bug in Django, it might be caused by ThreadingMixIn of Python's SocketServer module, which Django relies on. I didn't investigate it thoroughly though, so I'm not sure.

comment:8 Changed 14 months ago by mardini

  • Owner changed from nobody to mardini
  • Status changed from new to assigned

comment:9 Changed 14 months ago by mardini

  • Version changed from 1.6 to master

comment:11 Changed 14 months ago by mardini

  • Has patch set

comment:12 Changed 13 months ago by Tim Graham <timograham@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

In 4f72e5f03ae803fd9faa1445245c1050ca004526:

Fixed #21773 -- made daemon threads default in the development server.

Thanks clime for the report.

Note: See TracTickets for help on using tickets.
Back to Top