Starting with 4.3.0-dev-5-1, I now get:
---
compaudit:107: unknown group

with:
---
autoload -U compinit
compinit

in my .zshrc when logging in as root.  I don't get it as any
other user and this happens across multiple different machines.
This did not happen in 4.3.0-dev-2-4.

What groups is root in?  What NSS modules are used to fetch the groups?
What is the group ownership of every directory in root's $fpath and the
parent directories of those?

this is only coming from one of my machines that has this problem
(the simplest setup -- normal nsswitch.conf and such, but it also
happens on machines which are using LDAP; I'll be giving you the
one that doesn't though).

'group' (as root) returns: root

For NSS, my nsswitch.conf (again, on this one machine) has the
standard compat entry for passwd, group and shadow.  Nothing
fancy is happening on this machine.

'echo $fpath' gives me:
---
/usr/local/share/zsh/site-functions
/usr/share/zsh/4.3.0-dev-5/functions/Completion
/usr/share/zsh/4.3.0-dev-5/functions/Completion/AIX
/usr/share/zsh/4.3.0-dev-5/functions/Completion/BSD
/usr/share/zsh/4.3.0-dev-5/functions/Completion/Base
/usr/share/zsh/4.3.0-dev-5/functions/Completion/Cygwin
/usr/share/zsh/4.3.0-dev-5/functions/Completion/Darwin
/usr/share/zsh/4.3.0-dev-5/functions/Completion/Debian
/usr/share/zsh/4.3.0-dev-5/functions/Completion/Linux
/usr/share/zsh/4.3.0-dev-5/functions/Completion/Mandrake
/usr/share/zsh/4.3.0-dev-5/functions/Completion/Redhat
/usr/share/zsh/4.3.0-dev-5/functions/Completion/Unix
/usr/share/zsh/4.3.0-dev-5/functions/Completion/X
/usr/share/zsh/4.3.0-dev-5/functions/Completion/Zsh
/usr/share/zsh/4.3.0-dev-5/functions/Exceptions
/usr/share/zsh/4.3.0-dev-5/functions/MIME
/usr/share/zsh/4.3.0-dev-5/functions/Misc
/usr/share/zsh/4.3.0-dev-5/functions/Prompts
/usr/share/zsh/4.3.0-dev-5/functions/Zle
---

All of those exist, and so 'for i in `echo $fpath`; do ls -alF $i
| grep ' \./'; done' gives me:
---
drwxr-xr-x  2 root staff 48 2005-01-07 02:41 ./
drwxr-xr-x  14 root root  816 2006-02-28 00:19 ./
drwxr-xr-x   2 root root  352 2006-02-28 00:18 ./
drwxr-xr-x   2 root root  144 2006-02-28 00:18 ./
drwxr-xr-x   2 root root 1.7K 2006-02-28 00:18 ./
drwxr-xr-x   2 root root  376 2006-02-28 00:18 ./
drwxr-xr-x   2 root root  336 2006-02-28 00:18 ./
drwxr-xr-x   2 root root  960 2006-02-28 00:18 ./
drwxr-xr-x   2 root root  512 2006-02-28 00:18 ./
drwxr-xr-x   2 root root  72 2006-02-28 00:18 ./
drwxr-xr-x   2 root root  120 2006-02-28 00:18 ./
drwxr-xr-x   2 root root 5.7K 2006-02-28 00:18 ./
drwxr-xr-x   2 root root 1.3K 2006-02-28 00:18 ./
drwxr-xr-x   2 root root 2.0K 2006-02-28 00:18 ./
drwxr-xr-x   2 root root   96 2006-02-28 00:18 ./
drwxr-xr-x   2 root root  144 2006-02-28 00:18 ./
drwxr-xr-x   2 root root  528 2006-02-28 00:18 ./
drwxr-xr-x   2 root root  672 2006-02-28 00:18 ./
drwxr-xr-x   2 root root 1.4K 2006-02-28 00:18 ./
---

For the parent directories:
---
/usr/local/share/zsh:
drwxr-xr-x  3 root root   80 2005-01-07 02:41 ./

/usr/local/share:
drwxr-xr-x  8 root root 192 2006-02-14 00:31 ./

/usr/local:
drwxr-xr-x   9 root  root  240 2005-10-15 20:42 ./

/usr:
drwxr-xr-x   15 root root  344 2005-10-15 20:02 ./

/:
drwxr-xr-x   19 root root  488 2005-12-16 04:05 ./

/usr/share/zsh/4.3.0-dev-5/functions:
drwxr-xr-x  11 root root  528 2006-02-28 00:19 ./

/usr/share/zsh/4.3.0-dev-5:
drwxr-xr-x   4 root root 104 2006-02-28 00:18 ./

/usr/share/zsh:
drwxr-xr-x    4 root root  104 2006-02-28 00:18 ./

/usr/share:
drwxr-xr-x  165 root root 4.3K 2006-02-14 00:32 ./
---

        Let me know if you need anything else or if I didn't
answer your questions correctly.

Hi,

I can reproduce this bug with zsh-static 4.3.5-3. Here are some more
infos: (me is an ordinary user)

% HOME=/ strace -f zsh-static -c 'echo /usr/local/share/zsh/site-functions(f:g+ws:^g:staff:)'
[…]
open("//.zshenv", O_RDONLY|O_NOCTTY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/dev/null", O_RDONLY|O_NOCTTY|O_LARGEFILE) = 3
fcntl64(3, F_DUPFD, 10)                 = 11

So 11 is file descriptor for /dev/null.

close(3)                                = 0
fcntl64(11, F_GETFL)                    = 0x10000 (flags O_RDONLY|O_LARGEFILE)
fstat64(11, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
ioctl(11, TCGETS, 0xbfd3a188)           = -1 ENOTTY (Inappropriate ioctl for device)

Are you sure you can make this call for the special device /dev/null? The
ENOTTY suggests it requests a TTY.

mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x481bc000
_llseek(11, 0, [0], SEEK_CUR)           = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
ioctl(2, TCGETS, 0xbfd30b68)            = -1 EINVAL (Invalid argument)
write(2, "zsh:1: unknown group\n", 21zsh:1: unknown group
)  = 21
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], [CHLD], 8) = 0
exit_group(1)                           = ?

Bye, Jörg.

Hi Jörg.. the problem is that user/group lookups are disabled in the
-static build because glibc's NSS ABI is unstable and static binaries
still need to load NSS modules dynamically.

If we re-enable lookups, then zsh-static will segfault on any major libc
upgrade.  I don't know what the best solution here is.

Hallo Clint,

Clint Adams schrieb am Tue 26. Feb, 09:55 (-0500):

Are you shure it is the group lookup? From the strace I thought it is a
problem with ioctl call.

If it's a problem with the group lookup, maybe you can change it to a
“grep” in /etc/group. Another idea was to use the id of the group, but
zsh tries still to lookup the entry. Why? Maybe for a numeric id it could
skip the lookup.

Bye, Jörg.

Hallo Clint,

Clint Adams schrieb am Tue 26. Feb, 09:55 (-0500):

Another idea: What about linking with dietlibc or uClibc?

Bye, Jörg.

That's a pretty good idea.

I can reproduce this with zsh-static 4.3.6


Richard

block 354631 by 471208
block 354633 by 471208
quit

Adding blocking relationships.