New Fedora 22 Change proposal: systemd-sysusers

Simo Sorce simo at redhat.com
Fri Jul 11 09:41:42 UTC 2014


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



More information about the devel mailing list