Re: Multi-Minute Startup?

["Benjamin R. Haskell" <zsh@xxxxxxxxxx>]

On Thu, 7 Aug 2008, Aaron Davies wrote:
> On Thu, Aug 7, 2008 at 3:33 PM, Benjamin R. Haskell <zsh@xxxxxxxxxx> wrote:
> > Something similar came up just under a month ago on this list:
> >
> > ==
> > Eric D. Friedman wrote:
> > Subject: new-style completion and large numbers of users
> >
> > I'm using zsh 4.2.0 on a machine with a very large number of users. When I
> > first log on and do a completion of any kind, it triggers a cache-load of
> > all of the user names, which is quite time consuming. I'd like to disable
> > [...]
>
> [...]
>
> Looking at compaudit itself, it looks like it's still running "getent 
> group".

Looking at compaudit more closely leads me to think something might be 
awry with your environment variables (either LOGNAME or EGID). On my 
system (Gentoo w/Zsh 4.3.4), the parts of compaudit germane to getent are:


===============================
[[ -x /usr/bin/getent ]] || getent() {
  if [[ $2 = <-> ]]; then
    grep ":$2:[^:]*$" /etc/$1
  else
    grep "^$2:" /etc/$1
  fi
}

# ... trimmed

# RedHat Linux "per-user groups" check.  This is tricky, because it's very
# difficult to tell whether the sysadmin has put someone else into your
# "private" group (e.g., via the default group field in /etc/passwd, or
# by NFS group sharing with an untrustworthy machine).  So we must assume
# that this has not happened, and pick the best group.

local GROUP GROUPMEM _i_pw _i_gid _i_ulwdirs
if ((UID == EUID )); then
  getent group $LOGNAME | IFS=: read GROUP _i_pw _i_gid GROUPMEM
else
  getent group $EGID | IFS=: read GROUP _i_pw _i_gid GROUPMEM
fi
===============================

Is getent installed in /usr/bin on that machine? If not, maybe it's doing 
a grep over a large, generated file? (Three minutes seems excessive, 
though.)

If getent is there, maybe LOGNAME or EGID (whichever path is appropriate) 
is unset. So, instead of (w/ a username of 'aaron'):

getent group aaron | IFS=: read GROUP _i_pw _i_gid GROUPMEM
(finding a specific group's members, which should be fast, even over a 
long distance -- otherwise many common operations would be annoyingly 
slow)

it becomes:

getent group | IFS=: read GROUP _i_pw _i_gid GROUPMEM
(which should be slow, since you're reading all 10,000 groups)


Can you find the specific invocation of getent that's slow for you?

Best,
Ben