On Tuesday, Mar 25, 2003, at 23:29 US/Pacific, Matthew Seaman wrote:
Two things occur to me:
i) Did root use vipw(8) to edit the passwd database, or otherwise run:
# cap_mkdb /etc/master.passwd
when the UID was changed? It's the value in the hashed database cap_mkdb(1) builds that is used by the system. Updating that should have instantaneous effect.
Just used the pw command. However, note that this symptom persisted for over 24 hours. Last time it happened (on a 4.7 system) it persisted for several days if I recall, before I noticed/corrected it.
ii) You haven't said anything about what the source of your
password data is, which probably means you're just using the
flat file password database and not anything like NIS or LDAP.
Correct.
If you are using a distributed database, then a degree of
latency while changes get propagated around the servers is to
be expected. However, that shouldn't take any more than a few
minutes in a well configured system.
Right, and this is a standalone system (which is why I'm manually syncing up the uids in the first place).
The problem is not with the ls(1) command per se. It's the underlying
system library functions such as getpwuid(3) which do the translation
between numeric UIDs and usernames that are the seat of the problem.
You can see that by running some other command that uses getpwuid(3), eg:
% perl -e 'print scalar getpwuid(503), "\n";'
Got it. I think what I'll do is create a dummy user with the same conditions and let it persist for awhile so we can experiment with it.
KeS
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
