On Fri, Mar 3, 2017 at 3:36 AM, Jakub Hrozek <jhrozek@redhat.com> wrote:
On Thu, Mar 02, 2017 at 10:20:53PM -0500, Michael Smith wrote:
> I've been using sssd with AD on Ubuntu 16.04 for several months (sssd
> 1.13.4). I've joined probably a few dozen VMs to a domain. More often than
 
> I can reboot or restart sssd as many times as I like and it won't fix it.
> But as soon as I would bump up the debuglevel in /etc/sssd/sssd.conf and
> "systemctl restart sssd", everything would work.

The only explanation I have is that 'something', either some join script
or whatever is used updates sssd.conf after sssd is started. The way
sssd reads its configuration is that on sssd startup, we check the
timestamp of sssd.conf, compare it with the timestamp of sssd's internal
configuration database (/var/lib/sss/db/config.ldb) and if sssd.conf is
newer, sssd regenerates the configuration database.

And perhaps the problem is that the resolution of the timestamp is only
down to seconds, so if you update the config file on the same second as
the last restart, sssd migth not detect the config file was changed?

Oh, thanks, that must be it. I'm using Puppet to join so it may very well all happen within the same second. In fact, I see the module I'm using (walkamongus/realmd) has a block to remove the cache after updating sssd.conf, but there must be a race condition somewhere.

I'll add a line to the systemd unit to delete config.ldb before each start, something like "ExecStartPre=/bin/rm /var/lib/sss/db/config.ldb". Or is there a config option to force config.ldb to be generated each time sssd starts? I looked at it with tdbdump and it seems pretty small, probably not worth caching really. Or is there something in there that needs to be retained between runs?

Thanks,
Mike