[SSSD] Re: Watchdog in the monitor process
On 11/06/2016 06:21 PM, Jakub Hrozek wrote: Hi, Currently the watchdog is enabled for all sssd processes, including the main sssd process. I admit I only realised that now that I was looking into one user report where upgrading the sssd database during package update took so long that the watchdog eventually killed the sssd process..oops.. So we can either relax the watchdog during operations that we know might take a very long time (like upgrading huge cache files) or remove it altogether. I’m leaning towards the second option and just don’t setup the watchdog at all. Does anyone see a reason to keep the watchdog for the monitor? I think the watchdog in the current form makes sense only for “worker” processes where the monitor listens for SIGCHLD signals and restarts the services. I think for the monitor process it would make more sense to leverage some systemd functionality rather than kill itself :-) Remove it from the monitor. ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Watchdog in the monitor process
Make sense.. Killing itself is not proper design. Even systemd(Init process, system manager) has task of Managing services/daemons running on system included in duty list. Thanks Much!!! Amit Kumar On Sun, Nov 6, 2016 at 10:51 PM, Jakub Hrozekwrote: > Hi, > > Currently the watchdog is enabled for all sssd processes, including the > main sssd process. I admit I only realised that now that I was looking into > one user report where upgrading the sssd database during package update > took so long that the watchdog eventually killed the sssd process..oops.. > > So we can either relax the watchdog during operations that we know might > take a very long time (like upgrading huge cache files) or remove it > altogether. I’m leaning towards the second option and just don’t setup the > watchdog at all. > > Does anyone see a reason to keep the watchdog for the monitor? I think the > watchdog in the current form makes sense only for “worker” processes where > the monitor listens for SIGCHLD signals and restarts the services. I think > for the monitor process it would make more sense to leverage some systemd > functionality rather than kill itself :-) > ___ > sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org > To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org > ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Watchdog in the monitor process
Hi, Currently the watchdog is enabled for all sssd processes, including the main sssd process. I admit I only realised that now that I was looking into one user report where upgrading the sssd database during package update took so long that the watchdog eventually killed the sssd process..oops.. So we can either relax the watchdog during operations that we know might take a very long time (like upgrading huge cache files) or remove it altogether. I’m leaning towards the second option and just don’t setup the watchdog at all. Does anyone see a reason to keep the watchdog for the monitor? I think the watchdog in the current form makes sense only for “worker” processes where the monitor listens for SIGCHLD signals and restarts the services. I think for the monitor process it would make more sense to leverage some systemd functionality rather than kill itself :-) ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#46][comment] sss_client: Defer thread cancellation until completion of nss/pam operations
URL: https://github.com/SSSD/sssd/pull/46 Title: #46: sss_client: Defer thread cancellation until completion of nss/pam operations jhrozek commented: """ Well, if the old code would be disabled and there would be nobody using the new config option from the start, I'm fine with switching as well. """ See the full comment at https://github.com/SSSD/sssd/pull/46#issuecomment-258679368 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org