[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#438184: marked as done (getpwnam and getgrnam astonishing inefficiency)

Your message dated Thu, 16 Aug 2007 11:08:37 +0200
with message-id <20070816090837.GA17095@artemis.corp>
and subject line Bug#438184: getpwnam and getgrnam astonishing inefficiency
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message --- 
Package: libc6
Version: 2.3.6.ds1-13

While stracing dpkg I saw something strange so I investigated.

Below is a fragment showing dpkg on sarge installing libadns1-bin.
This is from the unpack phase and convers the installation of two
files.  I see similar behaviour on etch.

18 out of the 32 system calls for installing each file are the libc
reading /etc/{passwd,group} for get{pw,gr}nam in order to map "root"
to 0 for the nth time.

Surely it could be at least slightly more intelligent.

Ian.

00:54:58.376667 read(7, "./usr/bin/adnsheloex\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
00:54:58.376735 open("/etc/passwd", O_RDONLY) = 8
00:54:58.376791 fcntl64(8, F_GETFD)     = 0
00:54:58.376833 fcntl64(8, F_SETFD, FD_CLOEXEC) = 0
00:54:58.376876 _llseek(8, 0, [0], SEEK_CUR) = 0
00:54:58.376922 fstat64(8, {st_mode=S_IFREG|0644, st_size=5251, ...}) = 0
00:54:58.376996 mmap2(NULL, 5251, PROT_READ, MAP_SHARED, 8, 0) = 0x40022000
00:54:58.377041 _llseek(8, 5251, [5251], SEEK_SET) = 0
00:54:58.377093 munmap(0x40022000, 5251) = 0
00:54:58.377137 close(8)                = 0
00:54:58.377185 open("/etc/group", O_RDONLY) = 8
00:54:58.377238 fcntl64(8, F_GETFD)     = 0
00:54:58.377280 fcntl64(8, F_SETFD, FD_CLOEXEC) = 0
00:54:58.377321 _llseek(8, 0, [0], SEEK_CUR) = 0
00:54:58.377367 fstat64(8, {st_mode=S_IFREG|0644, st_size=1884, ...}) = 0
00:54:58.377440 mmap2(NULL, 1884, PROT_READ, MAP_SHARED, 8, 0) = 0x40022000
00:54:58.377487 _llseek(8, 1884, [1884], SEEK_SET) = 0
00:54:58.377538 munmap(0x40022000, 1884) = 0
00:54:58.377580 close(8)                = 0
00:54:58.377635 lstat64("/usr/bin/adnsheloex", {st_mode=S_IFREG|0755, st_size=9720, ...}) = 0
00:54:58.377721 rmdir("/usr/bin/adnsheloex.dpkg-new") = -1 ENOENT (No such file or directory)
00:54:58.377829 rmdir("/usr/bin/adnsheloex.dpkg-tmp") = -1 ENOENT (No such file or directory)
00:54:58.377888 open("/usr/bin/adnsheloex.dpkg-new", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0) = 8
00:54:58.378071 read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0@\213\4"..., 9720) = 9720
00:54:58.378324 write(8, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0@\213\4"..., 9720) = 9720
00:54:58.381611 read(7, "\0\0\0\0\0\0\0\0", 8) = 8
00:54:58.381688 fchown32(8, 0, 0)       = 0
00:54:58.381746 fchmod(8, 0755)         = 0
00:54:58.381794 close(8)                = 0
00:54:58.381844 utime("/usr/bin/adnsheloex.dpkg-new", [2007/08/16-00:53:53, 2006/10/17-17:47:03]) = 0
00:54:58.381924 link("/usr/bin/adnsheloex", "/usr/bin/adnsheloex.dpkg-tmp") = 0
00:54:58.382067 rename("/usr/bin/adnsheloex.dpkg-new", "/usr/bin/adnsheloex") = 0

00:54:58.382224 read(7, "./usr/bin/adnsresfilter\0\0\0\0\0\0\0\0\0"..., 512) = 512
00:54:58.382410 open("/etc/passwd", O_RDONLY) = 8
00:54:58.382478 fcntl64(8, F_GETFD)     = 0
00:54:58.382521 fcntl64(8, F_SETFD, FD_CLOEXEC) = 0
00:54:58.382566 _llseek(8, 0, [0], SEEK_CUR) = 0
00:54:58.382614 fstat64(8, {st_mode=S_IFREG|0644, st_size=5251, ...}) = 0
00:54:58.382689 mmap2(NULL, 5251, PROT_READ, MAP_SHARED, 8, 0) = 0x40022000
00:54:58.382739 _llseek(8, 5251, [5251], SEEK_SET) = 0
00:54:58.382853 munmap(0x40022000, 5251) = 0
00:54:58.382900 close(8)                = 0
00:54:58.382952 open("/etc/group", O_RDONLY) = 8
00:54:58.383006 fcntl64(8, F_GETFD)     = 0
00:54:58.383048 fcntl64(8, F_SETFD, FD_CLOEXEC) = 0
00:54:58.383092 _llseek(8, 0, [0], SEEK_CUR) = 0
00:54:58.383138 fstat64(8, {st_mode=S_IFREG|0644, st_size=1884, ...}) = 0
00:54:58.383211 mmap2(NULL, 1884, PROT_READ, MAP_SHARED, 8, 0) = 0x40022000
00:54:58.383257 _llseek(8, 1884, [1884], SEEK_SET) = 0
00:54:58.383307 munmap(0x40022000, 1884) = 0
00:54:58.383348 close(8)                = 0
00:54:58.383404 lstat64("/usr/bin/adnsresfilter", {st_mode=S_IFREG|0755, st_size=11528, ...}) = 0
00:54:58.383492 rmdir("/usr/bin/adnsresfilter.dpkg-new") = -1 ENOENT (No such file or directory)
00:54:58.383598 rmdir("/usr/bin/adnsresfilter.dpkg-tmp") = -1 ENOENT (No such file or directory)
00:54:58.383659 open("/usr/bin/adnsresfilter.dpkg-new", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0) = 8
00:54:58.383826 read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\0\213\4"..., 11528) = 11528
00:54:58.384050 write(8, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\0\213\4"..., 11528) = 11528
00:54:58.384206 read(7, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 248) = 248
00:54:58.384276 fchown32(8, 0, 0)       = 0
00:54:58.384326 fchmod(8, 0755)         = 0
00:54:58.384371 close(8)                = 0
00:54:58.384413 utime("/usr/bin/adnsresfilter.dpkg-new", [2007/08/16-00:53:53, 2006/10/17-17:47:03]) = 0
00:54:58.384486 link("/usr/bin/adnsresfilter", "/usr/bin/adnsresfilter.dpkg-tmp") = 0
00:54:58.384622 rename("/usr/bin/adnsresfilter.dpkg-new", "/usr/bin/adnsresfilter") = 0

--

--- End Message ---
--- Begin Message --- 
On Thu, Aug 16, 2007 at 12:06:09AM +0000, Ian Jackson wrote:
> Package: libc6
> Version: 2.3.6.ds1-13
> 
> While stracing dpkg I saw something strange so I investigated.
> 
> Below is a fragment showing dpkg on sarge installing libadns1-bin.
> This is from the unpack phase and convers the installation of two
> files.  I see similar behaviour on etch.
> 
> 18 out of the 32 system calls for installing each file are the libc
> reading /etc/{passwd,group} for get{pw,gr}nam in order to map "root"
> to 0 for the nth time.
> 
> Surely it could be at least slightly more intelligent.

  Yes, you can use nscd for that. And no, libc cannot be "more"
intelligent as things could live elsewhere than in /etc/passwd (ldap,
NIS, sql, whatever), and than monitoring isn't as easy for those other
backends.

  NSCD is the glibc way to keep an eye of NSS databases, and keep at
hand the things that are often asked. Note that nscd sucks big time for
hosts caching though, and that for that I'd recommend to use pdnsd or
similar software (bind ?) if you need to use some.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgpqLYHWD5ahD.pgp
Description: PGP signature


--- End Message ---
Reply to: