Not exactly sure what you are asking that you wouldn't already understand from how you know Apache works and what I already said.
For a reload, Apache parent process gets sent a SIGTERM signal. This causes the parent process to send a SIGTERM to its worker child processes, and to managed processes (ie., the mod_wsgi daemon processes). Each type of process will try and wait for current requests to finish, and then exit, but while they don't, the Apache parent process will keep sending them a SIGTERM every second. After a few seconds, if they have not exited, the Apache parent process will send them all SIGKILL. For a graceful restart, Apache parent process gets sent a SIGUSR2 signal. This causes the parent process to send a SIGUSR2 to its worker child processes, but it still sends a SIGTERM to managed processes. It doesn't give managed processes an option to perform any graceful restart. While waiting for its child worker processes to stop, it can create new child worker processes so it can handle new requests while still allowing current requests handled by existing processes to complete. For the managed processes though, it does the same thing as reload though, keep sending SIGTERM every second and then a SIGKILL after a few seconds. I said five seconds before, but think it may be three seconds in this scenario. The way Apache works internally, it isn't possible to have a graceful shutdown for managed processes, like those of mod_wsgi daemon processes, so you cannot override this behaviour. > On 13 Jun 2018, at 9:10 pm, Sujai Kumar <[email protected]> wrote: > > Thanks Graham for the response. > > I see that the httpd restart is working the way (reload) is supposed to work. > Could you please let us know how that is handled differently? > > Thanks & regards, > Sujaikumar > > On Wed, Jun 13, 2018 at 9:28 AM, Graham Dumpleton <[email protected] > <mailto:[email protected]>> wrote: > When using daemon mode of mod_wsgi that is how it works unfortunately. This > is because Apache only extends gracious shutdown to its own child worker > processes and not to managed daemon processes. > > So the daemon processes only get up to 5 seconds to terminate of their own > accord when sent the signal from the Apache parent process, before the Apache > parent will send them a SIGKILL. So if you have long running requests they > will get terminated if they run longer than 5 seconds. > > If this is an issue, the only option you would have is too not use logrotate > and use Apache's own mechanism for log file rotation, which doesn't have this > issue because it doesn't need a restart to work. > > You could also perhaps use mod_wsgi-express to run separately managed > instance, using its own log file rotation, and proxy from the main Apache > instance. > > Graham > >> On 13 Jun 2018, at 1:31 pm, Sujai Kumar <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hello All, >> >> As part of logrotate config, the httpd process is getting reloaded on a set >> time. I was of impression that this should not affect the django serving >> (under apache). On the contrary, I see that the django processes are killed >> abruptly on httpd reload. >> >> I read through the below documentation on apache stop/start/restart/reload >> and it says that the reload should be gracious (which I expected to be >> applicable to underlying django process too) >> >> https://httpd.apache.org/docs/2.4/stopping.html >> <https://httpd.apache.org/docs/2.4/stopping.html> >> >> On the other hand the httpd restart graciously restarts the underlying >> django process (Meaning: If a process is being served by django, all the >> other django processes that are not serving any requests currently goes for >> a restart and the one that is serving currently will wait for the current >> request to be served completely and then respawns again) >> >> >> I was expecting the reload behavior to be gracious to django process. Is >> there some setting that needs to be done specifically to tweak this >> behavior? Thanks. >> >> Thanks & regards, >> Sujaikumar >> >> -- >> 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 post to this group, send email to [email protected] >> <mailto:[email protected]>. >> Visit this group at https://groups.google.com/group/modwsgi >> <https://groups.google.com/group/modwsgi>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > 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 post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/modwsgi > <https://groups.google.com/group/modwsgi>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > 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 post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/modwsgi > <https://groups.google.com/group/modwsgi>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
