This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


On Sun, Sep 09, 2001 at 04:29:09PM +1000, Robert Collins wrote:
>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 :].

I understand that.  How could I not understand that?  I wrote the code and
I've already made this point.

What I'm saying is that if you have a sleep 999 running and touch /etc/hosts,
the sleep process will not wake up to reread /etc/passwd.  Ever.

If you are running bash, then *possibly* it will reread /etc/passwd the
next time you run a command.  I'm not interested enough to actually check.

It is quite possible that long running daemons will reread /etc/passwd when
they start a new process.  That is why I used that example.

However, how many times do you, in the normal course of a cygwin day,
touch anything in /etc?  /etc is supposed to contain relatively static
data.

Anyway, I'm not arguing against finer grained /etc/passwd checking, as
you noted, and Corinna has already implemented it, so...

>> 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".

I think I would have a hard time selling the concept of the necessity
to start a daemon if you want to run "make" on gcc.

Cygwin has to be able to work like it does now without the daemon.  I
think that is what Corinna was saying.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]