[Bug 231330] nscd does not work for long lines in /etc/group

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231330

            Bug ID: 231330
           Summary: nscd does not work for long lines in /etc/group
           Product: Base System
           Version: 11.2-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: bugs at FreeBSD.org
          Reporter: pa at chalmers.se

Created attachment 197057
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=197057&action=edit
Relevant config files and source for test program

If I have long entry in /etc/groups it looks like nscd fails to respond and I
get timeouts.

If I restart nscd, the first time I do getgrnam I get a cache miss and it works
as intended but on following calls it takes very long time:
=====
Restart nscd:
root at plywood:/users/pa # /etc/rc.d/nscd restart
Stopping nscd.
Waiting for PIDS: 63354.
Starting nscd.

Do getgrnam on the affected group (group entry about 3500 bytes):
plywood> time ./getgrnam testgroup1
testgroup1
gr_name=testgroup1
gr_gid=20000
0.000u 0.002s 0:00.00 0.0%      0+0k 0+0io 0pf+0w
plywood> time ./getgrnam testgroup1
testgroup1
gr_name=testgroup1
gr_gid=20000
0.000u 0.002s 0:16.26 0.0%      0+0k 0+0io 0pf+0w
plywood> time ./getgrnam testgroup1
testgroup1
gr_name=testgroup1
gr_gid=20000
0.000u 0.002s 0:16.09 0.0%      0+0k 0+0io 0pf+0w

On a not affected group (group entry about 1400 bytes):
plywood> time ./getgrnam testgroup2
testgroup2
gr_name=testgroup2
gr_gid=20001
0.000u 0.002s 0:00.00 0.0%      0+0k 0+0io 0pf+0w
plywood> time ./getgrnam testgroup2
testgroup2
gr_name=testgroup2
gr_gid=20001
0.000u 0.001s 0:00.00 0.0%      0+0k 0+0io 0pf+0w
plywood> time ./getgrnam testgroup2
testgroup2
gr_name=testgroup2
gr_gid=20001
0.000u 0.001s 0:00.00 0.0%      0+0k 0+0io 0pf+0w
======

If I enable debug in nscd and run nscd -nst I can see that the I/O is done by
query_socket_write when the entry is small and it works, but when the entry is
large it takes the path to query_io_buffer_write instead.

-- 
You are receiving this mail because:
You are the assignee for the bug.