Code

Opened 4 years ago

Closed 3 years ago

Last modified 3 months 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.

Attachments (0)

Change History (16)

comment:1 Changed 4 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

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 Changed 3 years ago by lukeplant

  • Type set to New feature

comment:3 Changed 3 years ago by lukeplant

  • Severity set to Normal

comment:4 Changed 3 years ago by guettli

  • 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 Changed 3 years ago by guettli

  • Version 1.1 deleted

comment:6 Changed 3 years ago by guettli

  • Cc hv@… added

comment:7 Changed 3 years ago by jezdez

  • Resolution set to fixed
  • Status changed from new to closed
  • Triage Stage changed from Accepted to Fixed on a branch

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

comment:8 Changed 2 years ago by mitar

  • Cc mmitar@… added

comment:9 follow-up: Changed 18 months ago by naktinis@…

jedez, could you point to an example?

comment:10 in reply to: ↑ 9 Changed 18 months ago by ptone

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 Changed 13 months ago by Fak3

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 follow-up: Changed 13 months ago by 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.

comment:13 in reply to: ↑ 12 Changed 13 months ago by Fak3

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 Changed 13 months ago by Fak3

  • Cc someuniquename@… added

comment:15 Changed 4 months ago by 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.

comment:16 Changed 3 months ago by guettli

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.