fritchie@thor.acc.stolaf.edu (Scott Fritchie; Systems Programmer) (03/17/90)
Greetings Net-Land,
I've sent this query to Dan Heller, but he has not heard of this problem
before, so if anyone has run into this bizarre problem, please post/mail
me. The problem is this:
We've been using Mush 6.5 here at St. Olaf for quite a while now. When 7.0
was released, I grabbed it as soon as possible to take advantage of the
bugfixes, etc. After compiling, 7.0 would seem to spin its gears forever,
never even getting to the "Mail User's Shell (7.0 ...)" startup message.
I've been very busy, so I haven't had a chance to find out why until now.
We're running 4.3 More/BSD with NFS from Mt. Xinu on 2 VAX 11/780's.
In init.c:init(), the call to getpwuid() gets stuck/never returns.
Poking around the code for the C library, I've found that an RPC call
within libc/yp/yp_match.c:yp_match() gets a bad exit status, so
yp_match() sleeps for a few seconds and tries again. Unfortunately, the
RPC call never succeeds, so the function never exits. (Actually, I found
that it did succeed once, after about 20 minutes of the RPC call, sleep,
etc. cycle.)
Whether or not you're familiar with the Mt. Xinu specifics or not may
not be necessary, I suppose. What is *odd*, though, is that all other
system programs which use getpwuid() work perfectly, regardless of
whether they were compiled last year or an hour ago. I even recompiled
Mush 6.5 yesterday to see if there was some problem with our C library,
but 6.5 works fine. However, 7.0 does not. It is very disconcerting,
to say the least.
I can't see what Mush could be doing to confuse Yellow Pages like that, but
if you've heard of this problem (and know of a fix), I'd really appreciate
it.
-Scott
---
Scott Fritchie, Systems Programmer and Postmaster
St. Olaf College, Northfield, MN 55057 USA
Domain: fritchie@acc.stolaf.edu UUCP: ..!umn-cs!stolaf!fritchie
"Yeah, boss, I'll be in late today. UNIX refuses to boot on my Ford."schaefer@ogicse.ogi.edu (Barton E. Schaefer) (03/17/90)
In article <11725@thor.acc.stolaf.edu> fritchie@thor.acc.stolaf.edu (Scott Fritchie; Systems Programmer) writes: } Greetings Net-Land, } } We're running 4.3 More/BSD with NFS from Mt. Xinu on 2 VAX 11/780's. } In init.c:init(), the call to getpwuid() gets stuck/never returns. } Poking around the code for the C library, I've found that an RPC call } within libc/yp/yp_match.c:yp_match() gets a bad exit status, so } yp_match() sleeps for a few seconds and tries again. Unfortunately, the } RPC call never succeeds, so the function never exits. The problem isn't getpwuid() itself, it's the combination with getuid(). I checked the Mt. Xinu man pages and /usr/include/{sys/types.h,pwd.h} files and discovered: typedef u_short uid_t; The man page says to declare: extern uid_t getuid(); but of course getpwuid() expects an int as argument, so it's throwing an invalid uid around. This doesn't cause any problems, apparently, unless you are running yp (which we aren't). You'll have to add a correct declaration for getuid() somewhere, and cast the call in the argument of getpwuid() to int. How the heck is one supposed to know how to portably declare things like getuid()? I presume uid_t is POSIX-compliant, but how do you detect at compile time that such a typedef exists? (And why the devil didn't Xinu use the *same* type as the argument to getpwuid()?) -- Bart Schaefer "EARTH: Surrender IMMEDIATELY or we PICKLE DAN QUAYLE" "THPPFT!" schaefer@cse.ogi.edu (used to be cse.ogc.edu)
jaap+@andrew.cmu.edu (Jaap Akkerhuis) (03/20/90)
Excerpts from netnews.comp.unix.questions: 17-Mar-90 Re: 7.0 & Mt. Xinu's getpwu.. Barton E. Schaefer@ogics (1585) > (And why the devil didn't Xinu > use the *same* type as the argument to getpwuid()?) I don't know, but Unix is riddled with these inconsistencies. Scanning for instance the AT&T SVID Issue 2, you will find that getuid() returns an unsigned short while setuid just expect an int, so the common code setuid(getuid()) is actually incorrect according to the SVID. It should be setuid((int)getuid()). Hopefully POSIX will get rid of all these problems, but I'm not holding my breath. When X/Open was in the process of producing their first version of the X/Open recomendations, they had corrected a lot of these anomalies. However, they had to retract that version on order of AT&T. This makes me wonder whether AT&T SVID will ever be POSIX compliant. jaap