Thanks Graham. On Wed, Jun 13, 2018 at 5:06 PM, Graham Dumpleton < [email protected]> wrote:
> 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]> 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]> 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 >> >> 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]. >> 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. >> >> >> >> -- >> 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. >> > > > -- > 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. > > > -- > 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. > -- 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.
