On Thu, 2014-07-10 at 20:05 +0200, Lennart Poettering wrote: > On Thu, 10.07.14 12:44, Simo Sorce (simo@xxxxxxxxxx) wrote: > > > On Thu, 2014-07-10 at 17:18 +0200, Jakub Hrozek wrote: > > > We /do/ plan on the syncing anyway, because some admins are > > > still used to vipw their passwd databases and there are legacy scripts > > > around, but still -- could we, when the SSSD interface is available, > > > call out from systemd-sysusers to the SSSD, with some fallback for > > > cases where SSSD is not running? > > > > Jakub, > > I think we can use inotify on /etc/passwd and friends and reread if > > someone modifies the file. > > This is not that easy actually as it sounds, because you need to be able > to cover the case where the passwd file is replaced by a different one > (which is actually the common case, since that's what makes updates to > the file atomic). But inotify is not particulraly nice for doing that, > especially if you want to cover the state where the file missing is > missing entirely... In that case you'd have to watch all of /etc, which > of course is something to avoid, since you might get woken up quite a > bit too frequently. > > My suggestion would be to simply check the mtime of /etc/passwd on each > query you get (well, but not more often than once per 1s or so), and > reread the file if the mtime changed. That way you have to issue one > stat() call every 1s if you are busy, and do nothing if you are > not. Which sounds like a good deal. Much simpler and safer than inotify. IIRC you can use inotify to get notified of deletes too, so you do not need to look at all of /etc, if /etc/passwd does not exist then you do not set up inotify and just stat if the file exists. 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. 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
