Re: [RFA] A kinder, gentler check for /etc/{passwd,group} changes

[Robert Collins <robert dot collins at itdomain dot com dot au>]

On Sun, 2001-09-09 at 15:40, Christopher Faylor wrote:
> On Sun, Sep 09, 2001 at 03:11:37PM +1000, Robert Collins wrote:

> >> /etc is supposed to be a relatively static area.  I think it is pretty
> >> unlikely that we'd be seeing noticeable performance hits unless people
> >> are making continual changes to that area.
> >
> >True, it can be hard to tell in advance though :}.
> 
> It's not even a matter of someone changing /etc a lot, actually.  You'd
> have to be changing /etc a lot and playing with uids a lot.  I don't
> think that there are many programs that do that.  inetd and sshd are
> the two that come to mind.

change anything in /etc, or /etc and it /etc/passwd and /etc/group will
be re-read. Thats my point :]. uids are irrelevant. editing
/etc/sshd_config will trigger a reread with the current code. But as you
say fine grained logic can come later.
 
> >> >The other thing that is worth considering (1.3.4/5 again) IMO is
> >> >putting the parsed user and group data into a mutex protected mmapped
> >> >area and having the daemon handle updating it.  That way there will be
> >> >even less overhead than there is today.
> >> 
> >> We could put the passwd data in the cygheap right now.  That would
> >> eliminate the need for execed processes to reread it.  The data is
> >> already stored in the heap, so forked processes already get to see it.
> >> 
> >> I did something like this a while ago but didn't see much of a
> >> performance gain, though.
> >
> >The difference in this I guess is that we are talking about having <n>
> >cygwin process's _all_ reread the passwd and group data when /etc
> >changes. If you have 40 or 50 cygwin process's running - say an XFree86
> >user - this may be rather noticable.
> 
> These processes aren't going to stop what they are doing every time /etc
> changes.  It will only be in the, IMO, rare event that they are playing
> with uids or gids that this would be an issue.

I thought that every action that requires uid or gid info will trigger a
check of the passwd|group state? Maybe I've got my wires crossed...

Nope. I don't think I'm wrong. _every_ getpwuid or related call checks
passwd_state. Every check of passwd_state will result in the change
notification being tested. And every time it's uninitialized the file is
reread.

In other words every process will stop what they are doing as soon as
they call _anything_ that calls getwpuid_r etc.

If what you meant was that it won't happen synchronously, then yes, sure
thats true. But on a busy system I wouldn't expect long periods without
file io :].

> The passwd and group manipulation are protected by your inclusion of
> mutexes.  The cygwin heap isn't shared between processes so there is no
> interprocess race possible.

Oh, ok. Well for the daemon I meant a globally shared memory region not
the heap (in case that wasn't clear).

> Except, for some iffiness when the heap is
> copied during a fork/exec.  There is an inherent problem with one thread
> modifying the cygwin heap while a another thread is execing or forking.
> It's roughly the same problem as what I recently reported for fork.

gotcha.

> >> This is one of the things about the daemon that trouble me.  If we
> >> put this kind of functionality in the daemon then cygwin will have
> >> to rely on it.  It won't be functional without it.  Either that or
> >> we'll have to keep the old code around -- which will lead to code
> >> bloat.
> >
> >I thought that was the point? We _cannot_ get some things done cleanly
> >and reliably without the daemon. This is why I suggested that the daemon
> >have an auto-start capability. That is that on 9x and NT if the daemon
> >is not running, it gets started by cygwin.. of course it won't be in the
> >System user context, but it should work? 
> 
> I think that Corinna mentioned that we have to have a cygwin that works
> without the daemon, actually:

Oh. How up for discussion is that? Or does that mean "Current
functionality shall remain without the deamon, new stuff can be daemon
dependent".

> While I like the idea of having a server maintain a /etc/passwd database
> for cygwin programs to access, I don't think that a program should have
> to start the server to find out its uid.
> 
> Maybe we just have a separate DLL that will stand in for the daemon
> when it is not available for some reason, that would be sufficient.
> Even there, I foresee mailing list wails about needing to include
> one more thing besides cygwin1.dll with their cygwin programs.
> 
> Just to be clear, I'm not against the idea of a server.  This was one of
> the ideas that I pitched to Cygnus when I first started working on
> Cygwin as my full time job in 1998.  It's one of the few things that I
> suggested that haven't been implemented by somebody since then.

'k.

Rob