Opened 14 years ago

Closed 13 years ago

Last modified 10 years ago

#13024 closed New feature (fixed)

Signal sent on application startup

Reported by: wojteks Owned by: nobody
Component: Core (Other) Version:
Severity: Normal Keywords:
Cc: hv@…, mmitar@…, someuniquename@… Triage Stage: Fixed on a branch
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I'd like to perform certain actions whenever my application starts running (via runserver or runfcgi, for each backend spawned). I don't want to do it in the middleware or on the request_started signal, because that's not elegant. So the best way would be for Django to send a 'server_initialized' signal whenever the server is finished preparing all the data, right before the listen call on the socket.

Change History (16)

comment:1 by Russell Keith-Magee, 14 years ago

Triage Stage: UnreviewedAccepted

This general has come up several times in the past, but I'm not aware of a ticket covering the problem. There are some issues to consider - not the least of which is when exactly to send the signal - but the general idea is sound and should be addressed.

comment:2 by Luke Plant, 13 years ago

Type: New feature

comment:3 by Luke Plant, 13 years ago

Severity: Normal

comment:4 by Thomas Güttler, 13 years ago

Easy pickings: unset
UI/UX: unset

There is a workaround on stackoverflow: http://stackoverflow.com/questions/2781383/where-to-put-django-startup-code

I think this workaround is ugly, a better solution is needed.

comment:5 by Thomas Güttler, 13 years ago

Version: 1.1

comment:6 by Thomas Güttler, 13 years ago

Cc: hv@… added

comment:7 by Jannis Leidel, 13 years ago

Resolution: fixed
Status: newclosed
Triage Stage: AcceptedFixed on a branch

Closing as this is fixed in a branch which needs review. See #3591.

comment:8 by Mitar, 12 years ago

Cc: mmitar@… added

comment:9 by naktinis@…, 11 years ago

jedez, could you point to an example?

in reply to:  9 comment:10 by Preston Holmes, 11 years ago

Replying to naktinis@…:

jedez, could you point to an example?

The most recent version of this work is on my branch - hopeful to get some version of this into 1.6:

https://github.com/ptone/django/blob/02d0fa3f14d1ad72958f403f16bdd662d200a558/django/apps/cache.py#L208

comment:11 by Evstifeev Roman, 11 years ago

Another issue, but related to this - where to bind signals?
Django documentation say that best place is put all bindings in the signals.py and import your signals.py somewhere in models.py. But that approach often results in circular import. Solving circuit is not always possible. For example if in signal binding "sender" argument refers back to model class.

Is there a ticket for signals issue? Is it worth to create one?

comment:12 by Russell Keith-Magee, 11 years ago

@Fak3 There isn't an explicit ticket for the binding problem AFAIK; however, it will be implicitly fixed by the App Refactor effort described by ticket #3591.

in reply to:  12 comment:13 by Evstifeev Roman, 11 years ago

Replying to russellm:

@Fak3 There isn't an explicit ticket for the binding problem AFAIK; however, it will be implicitly fixed by the App Refactor effort described by ticket #3591.

I can't find any fix for the general signal-binding issue in the mentioned github repository: https://github.com/ptone/django/compare/master...app-loading Is it in this repo and branch?

Maybe we are talking about different issues? I meant that currently there is a problem with properly importing signals.py in some cases (Not related to application startup special signals, but rather any model signals that may result in circular import)

comment:14 by Evstifeev Roman, 11 years ago

Cc: someuniquename@… added

comment:15 by anonymous, 10 years ago

One possible solution could be to overhaul the manage.py script which has two functions that can be edited. One for startup and the other for shutdown. So, the manage.py script could look something like

from django.core.management import BaseManager

class Manager(BaseManager):
    def startup(self):
        if (command == "runserver"):
            initialize_background_processes()
            generate_log_server_connection()
        elif (command == "syncdb"):
            generate_db_creation_log()
        # etc.

    def shutdown(self):
        send_process_shutdown_signals()
        close_log_server_connection()

if __name__ == "__main__":
    manager = Manager()

Essentially, my envisioned manage.py script would allow users to generate functionality on the startup and shutdown of the script. Then, someone could add additional functionality when specific commands are called. I think this solution is more elegant than creating middleware or custom startup commands. This will make the process of running a server with any desired custom functionality much clearer.

comment:16 by Thomas Güttler, 10 years ago

Just for the docs: With Django 1.7 there is a callback, which can be implemented: ready():

https://docs.djangoproject.com/en/dev/ref/applications/#django.apps.AppConfig.ready

It gets called if the application is loaded. But it is called for non web usage, too (e.g. cron jobs).

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