On Thu, 2014-07-10 at 20:05 +0200, Lennart Poettering wrote:
On Thu, 10.07.14 12:44, Simo Sorce (simo(a)redhat.com) 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