Signal sent on application startup

[wojteks]

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.

[Russell Keith-Magee]

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.

[Thomas Güttler]

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.

[Jannis Leidel]

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

[naktinis@…]

jedez, could you point to an example?

[Preston Holmes]

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

[Evstifeev Roman]

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?

[Russell Keith-Magee]

@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.

[Evstifeev Roman]

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)

[anonymous]

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.

[Thomas Güttler]

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).