On (23/02/16 23:50), Harald Dunkel wrote:
>Hi Lukas,
>On 02/23/16 13:46, Lukas Slebodnik wrote:
>> On (23/02/16 13:01), Harald Dunkel wrote:
>>> On 02/23/2016 11:58 AM, Lukas Slebodnik wrote:
>>>> I would rather focus on different thing. Why is sssd_be process blocked 
>>>> for long time?
>>> I have no idea. Was it really blocked?
>> It needn't be blocked itself. But it was busy with some non-blocking 
>> operation which main process considered as bad state.
>Do you think this is OK? Did it try to terminate the unresponsive
>sssd_be, or did it just try to start a new one and ran into a
>conflict with the old?
It never tries to start new one.
It just restart old one.

>> Would you mind to share sssd log files with high debug level?
>Surely I can increase the log level for sssd. I wonder why
>sssd_be doesn't write its own log file?
Only critical error messages are logged by default
therefore you need to increase debug_level.

>>> Does it really have to be watched? Wouldn't it be the job of systemd to 
>>> restart the service when it dies?
>> sssd works also on non-systemd distribution. We plan to reply on systemd. If 
>> you want to speed-up process then patches are always welcomed.
>I highly appreciate your effort on providing compatibility with
>sysv init and others, but do you know that ipa-client-install (4.0.5)
>dies without systemd? I cannot tell for more recent ipa versions,
>since they are not available for Debian 8.
It's not problem of sssd but ipa-client-install.

ipa-client-install != sssd.
ipa-client-install just configure sssd to work with FreeIPA.

sssd can work also with plain LDAP and/or Active Directory.

>> And moreover systemd would not solve the main issue. we should try to find 
>> out why sssd_be did not respond for long time.
>Maybe it would help to improve the way how the monitor checks for un-
>responsive threads instead? We have no indication that sssd_be had
>any problem, except for sssd trying to start a new one. Since sssd
                                        restart sssd_be
>couldn't I would assume that the old sssd_be was still up and running
>and that sssd was the buggy part.
I woudl not assume it.

But let's try to find out why sssd_be did not respond for long time.


Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to