It is not an arbitrary timeout as you can set the length of it. :-) Anyway, if you need better control send SIGINT to your own process ID if you know the condition is satisfied. This should stop accepting of new requests by that process. Don't use SIGUSR1 as that triggers a graceful shutdown of the process so new requests will still be accepted until the shutdown sequence kicks in after the graceful timeout.
> On 6 May 2020, at 5:32 am, Kent <[email protected]> wrote: > > 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] <>> 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] <>. >> 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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/29dc0223-b705-42fd-a1dc-53e9b88109c1%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/29dc0223-b705-42fd-a1dc-53e9b88109c1%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/15947F87-F670-40CA-8E64-B9D419CABD56%40gmail.com.
