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.
LS
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
