Unfortunately we haven't seen any new issues since turning debug under the domain section to 9.
So when sssd shutdowns down and restarts due to missing "pings" to the service named after the domain, should we be blocked on access? We understand for sec reasons its often times better to fail closed, like a fw breaking but locking/closing all ports, but what about if a user is leveraging this on his laptop? remotely and/or on wifi? I would expect the last local copy of the sss database/cache should be used to let them login
During this process when sssd shuts down, its not like its removing the cache under /var/lib/sss/db.
Should we ever see a point where sssd won't let you login due to the domain service timeout?

as always, thanks for the continued help/education in these matters

On Thu, Jan 19, 2017 at 10:06 AM, jsl6uy js16uy <js16uy@gmail.com> wrote:
roger roger
thanks very much for the suggestion will do

On Thu, Jan 19, 2017 at 12:48 AM, Lukas Slebodnik <lslebodn@redhat.com> wrote:
On (18/01/17 14:34), jsl6uy js16uy wrote:
>Hello all, hope all is well
>Seeing an odd issue on a host.  Periodically sssd will state it can't ping
>the domain...well the service named the same as the domain....and then
>shutdown and restart. Users can't auth and login till the service restarts.
>So this effectively restricts access to hosts to filtered users like root
>
>Windows DCs are available the whole time. See nothing untoward in a pcap
>during that time. Also, since we've been having these issues, the host has
>not been used for prod duty, so lightly loaded, during these sssd
>disconnects. Really see heavy traffic to the DCs during the issue.
>What does it mean for a service ping to timeout in sssd speak? Service on
>the dbus?
>Posted snippets from journalctl/sssd logs/sssd.conf all below
>
>thanks in advance, any and all help would be appreciated
>


>
>host is ubuntu xenial
>
>from journalctl......from the event today
>Jan 18 12:51:55 X sssd[41083]: Killing service [foo], not responding to
>pings!
>Jan 18 12:52:08 X sshd[104273]: fatal: Access denied for user srv_ti by PAM
>account configuration [preauth]
>Jan 18 12:52:52 X sshd[104298]: Connection closed by 99.99.99.99 port 60245
>[preauth]
>Jan 18 12:52:55 X sssd[41083]: [foo][41084] is not responding to SIGTERM.
>Sending SIGKILL.
>Jan 18 12:52:55 X sssd[be[104300]: Starting up
>
>sssd_log today at debug 9 set in sssd.conf
>
I would recommend to increase debug_level also in domain section
(7 might me enought for this purpose) and then check what is going on
at the problematic time in sssd_domain.log

LS
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org