Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!rice!sun-spots-request From: ehrlich@shire.cs.psu.edu (Daniel R. Ehrlich) Newsgroups: comp.sys.sun Subject: A disgruntled user poses a question about YP Keywords: SunOS Message-ID: <3508@kalliope.rice.edu> Date: 19 May 89 13:32:57 GMT Sender: usenet@rice.edu Organization: Sun-Spots Lines: 129 Approved: Sun-Spots@rice.edu X-Sun-Spots-Digest: Volume 8, Issue 4, message 11 of 13 One of our more knowledgable users has made a few observations about YP running under SunOS 4 and has posed a number of questions that some sun-spotters may be able to answer. If someone has any insights we would appreciate hearing from you. Thanks in advance. --Dan Ehrlich ------- Forwarded Message from dae@shire.cs.psu.edu: Imagine the following tiny, innocent little program. All it wants to do is get information out of the password file. #include main() { struct passwd *pw; while (pw = getpwent()) close(255); endpwent(); exit(0); } Now imagine that poor, tiny little program meeting the dreaded monster we all loathe, YP (as of SunOS 4.0). The close(255)'s are so we can see what's happening in a system call trace. I've deleted stuff from the beginning relating to the shared library loader (that's for another piece of mail). ********************************************************************** * YP wakes up and starts mumbling ************************************ ********************************************************************** getdomainname ("", 256) = 0 open ("/etc/passwd", 0, 0666) = 3 ioctl (3, 0x40125401, 0xf7fff366) = -1 ENOTTY (Inappropriate ioctl for device) fstat (3, 0xf7fff3d8) = 0 brk (0xc0b8) = 0 ********************************************************************** * The next lines deal with lines that were in /etc/passwd. *********** ********************************************************************** read (3, "root:AkiKKWAJsne5I:0:1:Superuser".., 8192) = 1895 close (255) = -1 EBADF (Bad file number) close (255) = -1 EBADF (Bad file number) close (255) = -1 EBADF (Bad file number) close (255) = -1 EBADF (Bad file number) close (255) = -1 EBADF (Bad file number) close (255) = -1 EBADF (Bad file number) close (255) = -1 EBADF (Bad file number) close (255) = -1 EBADF (Bad file number) close (255) = -1 EBADF (Bad file number) close (255) = -1 EBADF (Bad file number) close (255) = -1 EBADF (Bad file number) close (255) = -1 EBADF (Bad file number) close (255) = -1 EBADF (Bad file number) close (255) = -1 EBADF (Bad file number) close (255) = -1 EBADF (Bad file number) close (255) = -1 EBADF (Bad file number) ********************************************************************** * Now it gets really bad. The first YP call is very difficult, * involving, among other things, * -> 1 call to ioctl() * -> 2 calls to open() (on the same file) * -> 2 calls to flock() (on the same file, failing both times) * -> 2 calls to socket() * -> 2 calls to gettimeofday() * -> 3 calls to getpid() (in case we fork() in the middle of getpwent()) * -> 3 calls to bind() (two of which fail, for different reasons) * Maybe this is why SunOS runs like a pig on small machines? ********************************************************************** getpid () = 1036 open ("/var/yp/binding/cs.psu.edu.2", 0, 036734075701) = 4 flock (4, 06) = -1 EWOULDBLOCK (Operation would block) read (4, "".., 2) = 2 close (4) = 0 socket (2, 2, 0) = 4 bind (4, "".., 16) = -1 EADDRINUSE (Address already in use) close (4) = 0 open ("/var/yp/binding/cs.psu.edu.2", 0, 0) = 4 flock (4, 06) = -1 EWOULDBLOCK (Operation would block) lseek (4, 2, 0) = 2 read (4, "".., 12) = 12 close (4) = 0 gettimeofday (0xf7fff2c0, 0) = 0 getpid () = 1036 socket (2, 2, 17) = 4 getpid () = 1036 bind (4, "".., 16) = -1 EACCES (Permission denied) ioctl (4, 0x8004667e, 0xf7fff28c) = 0 fcntl (4, 02, 0x1) = 0 bind (4, "".., 16) = 0 getsockname (4, 0xf7fff334, 0xf7fff354) = 0 sendto (4, "".., 88, 0, 0x46b8, 16) = 88 getdtablesize () = 64 select (64, 0xf7fff2e4, 0, 0, 0x46cc) = 1 recvfrom (4, "".., 1600, 0, 0xf7fff2d0, 0xf7fff2e0) = 112 gettimeofday (0xf7fff468, 0xf7fff460) = 0 close (255) = -1 EBADF (Bad file number) ********************************************************************** * Now things settle down into a pattern. Not bad, 10 system calls * per query. ********************************************************************** getpid () = 1036 open ("/var/yp/binding/cs.psu.edu.2", 0, 036734075701) = 5 flock (5, 06) = -1 EWOULDBLOCK (Operation would block) read (5, "".., 2) = 2 close (5) = 0 getsockname (4, 0xf7fff344, 0xf7fff354) = 0 sendto (4, "".., 88, 0, 0x46b8, 16) = 88 select (64, 0xf7fff2e4, 0, 0, 0x46cc) = 1 recvfrom (4, "".., 1600, 0, 0xf7fff2d0, 0xf7fff2e0) = 104 gettimeofday (0xf7fff468, 0xf7fff460) = 0 close (255) = -1 EBADF (Bad file number) ********************************************************************** Ok, question time. * Does anybody at Sun use the trace program? * There are 14 characters in /var/yp/binding/cs.psu.edu.2. Why do we only look at the first two? * Why doesn't it like the first (TCP?) socket? * Is there nothing we can do to avoid doing one namei() per query? It is, after all, probably the single hardest thing for the kernel to do... * What is the flock() supposed to do? What would we do differently if it worked? Should it succeed? Who has it locked? * Does Hesiod work yet? Are there any other alternatives to YP? Please? Daemon