On Fri, 2014-07-11 at 12:52 +0200, Lennart Poettering wrote: > On Fri, 11.07.14 05:41, Simo Sorce (simo@xxxxxxxxxx) wrote: > > > The reason why we *must* use a notification mechanism is that we > > maintain a very fast cache as a mmapped database to avoid roundtrips > > from applications, so we simply *do not* know when someone looks up data > > there. This means we need to proactively monitor /etc/passwd and > > invalidate/change data in the cache when it changes. > > Well, if you do this asynchronously, then this will always be racy: > think of an admin who edits /etc/passwd, and immediately checks back if > the entry is there, with "getent passwd" or so. He will race against > your reload logic: sometimes he might be quicker, sometimes > sssd. Sometimes the new entry will exist sometimes it won't. > > If you want to fix the race, then your client libs for the mmap > structure should probably have enough logic to compare the mtime of the > files with some timestamp in the mmap, before using the data. And if the > mtime is out of date it needs to ping the server, to sync on. But if you > do that, then there's really no need for inotify, again... This means stating for every single getpwnam() or getgrnam(), etc ... but yes I am aware of the corner cases (I already wrote an email to sssd-devel@ highlighting another, more important one, this morning), and we'll experiment a bit to find the best course of action. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
