[SSSD] Re: Watchdog in the monitor process

2016-11-06 Thread Pavel Březina

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

2016-11-06 Thread Amit Kumar
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 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 :-)
> ___
> 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

2016-11-06 Thread Jakub Hrozek
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

2016-11-06 Thread jhrozek
  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