Graham, Thank you for replying.
I am indeed using daemon mode. In these conditions, I reach the "mod_wsgi (pid=%d): Target WSGI script '%s' cannot be loaded as Python module." error. My concern is that, until that somewhat arbitrary timeout occurs, Apache will happily continue to send requests to this child process, even though I've already detected its configuration has been messed up permanently. Wouldn't it be better in these circumstances to signal a shutdown so that Apache doesn't send more requests to this process, maybe with signal.SIGUSR1? (Does SIGUSR1 do anything different from SIGINT, BTW?) Thanks again, Kent On Monday, May 4, 2020 at 5:30:28 PM UTC-4, Graham Dumpleton wrote: > > You need to use daemon mode and then use the 'startup-timeout' option to > WSGIDaemonProcess. > > It was primarily added to cope with how Django initialisation is now no > longer reentrant and so if an error occurs during startup, the process can > be forced to restart after talking too long. This is intended to replace > the use of os.kill() you may see examples of out there for doing the same. > > On 4 May 2020, at 9:58 pm, Kent <[email protected] <javascript:>> wrote: > > I'm hoping for a recommendation for dealing with the (rare) exception that > could happen during initial application loading which ends up corrupting > the application. > > While rare, I've seen that, for example, an unfortunately-timed database > disconnection which happens to occur *during initial *application load > and configuration, but after most other configuration leads to an unusable > wsgi process (it is half-cooked). All subsequent requests Apache sends to > this process attempts to load the application (again) but it is in a state > which causes an exception every time (because it was partly already > configured). > > I've considered wrapping the delicate start-up code section in a > try-except block that would signal itself for termination so that Apache > restarts that child: > > os.kill(os.getpid(), signal.SIGINT) > > > But I wanted to check whether there is a "preferred" or better approach to > dealing with this circumstance? > > Thanks in advance! > Kent > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/5b325ada-b68b-4bb4-902f-ba2b7560cd00%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/5b325ada-b68b-4bb4-902f-ba2b7560cd00%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/29dc0223-b705-42fd-a1dc-53e9b88109c1%40googlegroups.com.
