Unix-Wizards-Request@arpa.brl (Mike Muuss) (06/27/88)
UNIX-WIZARDS Digest Mon, 27 Jun 1988 V5#081
Today's Topics:
Re: I want my bug-free NFS patch!
Re: "text: table is full" error message
Re: sh(1) command substitution and here documents
Re: grep replacement
/dev/stdin
Why DEC doesn't need an ABI
Re: What do panic messages mean?
Re: SVVS (was OSF discussion)
Re: Why DEC doesn't need an ABI
Re: wasting VM: the Sun philosophy (was Re: grep replacement)
RTFM on sendmail (was Re: C Finite Elements?)
-----------------------------------------------------------------
From: der Mouse <mouse@mcgill-vision.uucp>
Subject: Re: I want my bug-free NFS patch!
Date: 26 Jun 88 05:47:48 GMT
Posted: Sun Jun 26 01:47:48 1988
To: unix-wizards@SEM.BRL.MIL
In article <9514@eddie.MIT.EDU>, nessus@athena.mit.edu (Doug Alan) writes:
> I just installed a patch to NFS that allows you to mount the entire
> filesystem of a remote computer, rather than having to mount all of
> its individual disk partitions.
> The most prominent bug is as follows: Let's say the NFS server is
> called "server" and you are using a client machine. [Server has
> local disk partition /c. server:/ is mounted on /@/server. we cd to
> /@/server/c/foodir, pwd says /foodir instead.]
When I was writing my NFS server, I ran into similar problems. This
sounds very much as though the inumbers in the returned structures are
the real disk inumbers - which is wrong. This leads to the server
seeing the rather unpleasant situation of two distinct files having the
same (dev,inum) pair. My solution was to stripe the space of available
inumbers, based on the number of local disk partitions on the server.
However, given that you're using a patch to an existing NFS
implementation, you don't have the freedom to do this. I think you're
pretty much out of luck, unless you want to dive rather deeply into the
NFS implementation on the server.
Why does this cause the above anomoly with pwd? Because getwd (in pwd)
reads .. and finds the inumber for .; this gives it the foodir part.
Then it looks at ../.. and notices it has the same inumber as ..,
because they're both roots of filesystems on the server (server's / and
/c are both filesystem roots on the server, so they're both inode 2 -
the device number gets lost by the time they reach the client).
Normally, the only time foo/ and foo/.. have the same (dev,inum) is
when foo is /, so getwd assumes it's reached /. Try mounting the disk
on the server somewhere else, instead of /c. Make it somewhere at
least two levels down in the hierarchy: /etc/bardir, say. Then try cd
/@/server/etc/bardir/foodir and see what pwd has to say. This time,
you see, getwd() will not see two consecutive directories with the same
inumber as it winds its way up through .., ../.., ../../.., etc.
By now some of you may be wondering how come files with the same
inumber don't get confused with one another. This is because files are
accessed by file handles, not inumber. And the file handles,
presumably, are different. (If they weren't, such files *would* get
confused.)
> I have also just noticed another problem since installing this patch.
> I cannot say whether or not this bug has always been there, or
> whether it appeared upon installing this patch. This problem is
> intermittent and I can not reproduce it on demand. I was looking at
> a text file that was on the remote machine. Unfortunately, there
> appeared to be a bunch of nulls on the end of the file that weren't
> really there. On this particular file, the problem was reproducable
> for a while, but eventually it stopped happening.
The problem persisted for as long as the block was present in the
client's buffer cache, I feel sure. The question then is "how did it
get there?". Are the filesystem mounts hard or soft (ie, do timeouts
cause the operation to fail or to retry indefinitely)? With soft
mounts, the client implementation may wind up producing a bufferful of
nulls when it shouldn't. If this is what's happening, it's a bug.
I could also see this being due to a race condition: the client tries
to read the last block of the file, based on its idea of the size of
the file. However, in between its getting the size of the file and its
attempt to read the last block, someone else (another client, or a
process on the server) truncates the file to a shorter size. The
result may well be a bufferful of nulls.
der Mouse
uucp: mouse@mcgill-vision.uucp
arpa: mouse@larry.mcrcim.mcgill.edu
-----------------------------
From: der Mouse <mouse@mcgill-vision.uucp>
Subject: Re: "text: table is full" error message
Date: 26 Jun 88 08:19:43 GMT
Posted: Sun Jun 26 04:19:43 1988
To: unix-wizards@SEM.BRL.MIL
In article <507@spp3.UUCP>, simpson@spp3.UUCP (Scott Simpson) writes:
> We are running stock SunOS 3.5 on a Sun 3/60 (diskless) and we keep
> getting the error message "text: table is full" error message after
> our Suns have been up a bit. [...] I have even gotten these error
> messages when I have only 1 shell running and I am the only person on
> the machine.
Growing the text table may do nothing but increase the time your
machine can be up until it dies. I understand that under some
circumstances, when an NFS server fails (times out) when the client is
trying to demand-load text segment pages from the image file, the
client's kernel may lose a text table slot. And if you run out of text
table slots this way? The only cure I know of is to reboot the client.
> How do you make your text table bigger? (We are a binary site).
The simple way is to patch ntext in /vmunix and reboot:
# adb -w /vmunix
_ntext?D
_ntext:
_ntext: 28
(Hmmm, 28 slots? Let's up it to 50.)
_ntext?W 0t50
_ntext: 0x1c = 0x32
$q
(There. Now reboot....)
# /etc/fastboot
(Some things can be patched in the running kernel and take effect
immediately. _ntext is not one of these; you must patch the kernel
file and reboot.)
This change will go away next time you build a kernel. Most kernel
configuration schemes have a way to override the default values for
things like ntext; see param.c in your system configuration directory.
der Mouse
uucp: mouse@mcgill-vision.uucp
arpa: mouse@larry.mcrcim.mcgill.edu
-----------------------------
From: Shutoku Shia <smileyf@ucscb.ucsc.edu>
Subject: Re: sh(1) command substitution and here documents
Date: 26 Jun 88 01:10:55 GMT
Sender: usenet@saturn.ucsc.edu
To: unix-wizards@brl-sem.arpa
one other soln. is (instead of using here doc):
#!/bin/sh
float_var=`echo "scale = 4; 3/4" | bc"`
Shutoku Shia
-----------------------------------------------------------------------
| Bitnet: smileyf@ucscf.bitnet | formerly in |
| Internet: smileyf@ucscf.UCSC.EDU | Dept. of Cmp. & Info. Sci. |
| Arpanet: smileyf@ucscf.UCSC.EDU | Univ. of Calif., Santa Cruz |
| Uucp: ...!ucbvax!ucscc!ucscf!smileyf | |
-----------------------------------------------------------------------
-----------------------------
From: Shutoku Shia <smileyf@ucscb.ucsc.edu>
Subject: Re: sh(1) command substitution and here documents
Date: 26 Jun 88 01:15:20 GMT
Sender: usenet@saturn.ucsc.edu
To: unix-wizards@brl-sem.arpa
In article <3920@saturn.ucsc.edu> smileyf@ucscb.UCSC.EDU (Shutoku Shia) writes:
>one other soln. is (instead of using here doc):
>
>#!/bin/sh
>float_var=`echo "scale = 4; 3/4" | bc"`
-
I made a mistake here .. there should be no double quote following
bc.
Shutoku Shia
-----------------------------------------------------------------------
| Bitnet: smileyf@ucscf.bitnet | formerly in |
| Internet: smileyf@ucscf.UCSC.EDU | Dept. of Cmp. & Info. Sci. |
| Arpanet: smileyf@ucscf.UCSC.EDU | Univ. of Calif., Santa Cruz |
| Uucp: ...!ucbvax!ucscc!ucscf!smileyf | |
-----------------------------------------------------------------------
-----------------------------
From: der Mouse <mouse@mcgill-vision.uucp>
Subject: Re: grep replacement
Date: 26 Jun 88 08:44:27 GMT
Posted: Sun Jun 26 04:44:27 1988
To: unix-wizards@SEM.BRL.MIL
In article <8167@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon S. Allbery) writes:
> As quoted from <5826@umn-cs.cs.umn.edu> by randy@umn-cs.cs.umn.edu (Randy Orrison):
>> In article <7962@alice.UUCP> andrew@alice.UUCP writes:
[ various things, originally about context grep. But when replying,
++Brandon (do you still use that name, Brandon?) says.... ]
> (My /dev/stdin complaint earlier was [...] aimed at the person who
> informed the entire Usenet that "hey, I posted a /dev/stdin driver
> source for 4.2BSD, so not a one of you has any reason not to be
> running it". In other words, the usual 4.xBSD-source elitism.)
That person was Chris Torek, but if he'd been a bit slower it could
well have been me. At least he didn't say it as abrasively as your
summary does.
However, if you check back and look at the original postings on this
issue, the /dev/stdin point was first brought up as follows:
> 22) support a filename of - to mean standard input.
> a unix without /dev/stdin is largely bogus but as a sop to the poor
> barstards having to work on BSD, gre will support -
> as stdin (at least for a while).
(This over Andrew Hume's signature. He was explaining what features
gre would support.)
With phrasing like that, I can hardly blame Chris for rising to the
defense of his driver. And note the "BSD" phrase: that's the context
in which Chris said there was no excuse for complaining about not
having /dev/stdin. And in that context, I agree with him.
And there's no call for complaints about source elitism. My /dev/stdin
driver can be added to a binary distribution; surely Chris' can too.
(Andrew, there's no call to be so insulting. Lots (most?) of us who
use BSD don't think of ourselves as "poor barstards[sic]" who "have" to
work on BSD. There are two SysV-based machines here I can use whenever
I feel like it; I find it extremely painful to try to do anything on
them. But you generally don't find me talking about "poor bastards who
have to work on SysV", and you most certainly won't find me saying so
in my postings to the entire net.)
der Mouse
uucp: mouse@mcgill-vision.uucp
arpa: mouse@larry.mcrcim.mcgill.edu
-----------------------------
From: Tom Newcomb <newcomb@cory.berkeley.edu>
Subject: /dev/stdin
Date: 26 Jun 88 13:51:58 GMT
Sender: news@pasteur.berkeley.edu
To: unix-wizards@SEM.BRL.MIL
After reading all the flap about /dev/stdin (and its omission from BSD UNIX), I
thought a while about the problem. First, is /dev/stdin supposed to be just a
link of sorts to one's TTY input? I can't think of anything else it should
reference, except perhaps fd0 in a shell script (and here, admittedly, my
case is worthless). If you want to do something like:
egrep 'Lo\! The Hounds of Hell eat Puppy Chow\!' `cat files /dev/stdin`'
then would not /dev/stdin be referring to TTY input? I should think that it
would always be used on command lines where stdin is not being redirected; I
don't know of too many programs that let you get away with something like this:
cat /dev/stdin < whangdoodle ; Send stdin and 'whangdoodle' to stdout
(Would /dev/stdin in this case be referring to 'whangdoodle', since it's now
standard input...?)
So, if all you want is the TTY input, why not use /dev/tty? It's worked
beautifully in all the cases I've tried. So, what am I missing? Can anybody
come up with a case where /dev/stdin would NOT be /dev/tty, besides shell
scripts? (I already know this won't work for scripts run from a shell whose
input has been redirected.) In a C program, also, you can just do an
fdopen(3) on descriptor 0 (and that ALWAYS works).
PLEASE send comments through E-MAIL!!!! I promise I'll summarize in a week or
so. Many thanks.
Tom Newcomb | WEST, v. West is what wabbits do when they
newcomb@cory.Berkeley.EDU | get tired of wunning awound.
-----------------------------
From: "Brandon S. Allbery" <allbery@ncoast.uucp>
Subject: Why DEC doesn't need an ABI
Date: 26 Jun 88 16:07:01 GMT
To: unix-wizards@SEM.BRL.MIL
I believe we're all aware that DEC was denied an ABI for the VAX processor
line. DEC was rather annoyed about it. But I contend that DEC has no need
for a VAX ABI.
Why, you ask?
An ABI exists so that different manufacturers porting UNIX systems to a
particular processor can run the same programs, simplifying things for
applications developers. Now: it makes sense to do this for the plethora
of 80386 machines and 680x0 machines out there -- but for a VAX? Consider
that (a) DEC does not license the VAX processor for anyone else's use, and
(b) DEC sells the only true commercial VAX UNIX.
The hardware question is obvious. As for Unixes for a VAX, we have: BSD
4.4 (it's a bit late to retrofit 4.[23] into an ABI, which also takes
mtXinu out of the picture), Mach, and (potentially) Gnu. But Mach and
4.4BSD are *research* Unixes; as a result, they can experiment with new
applications interfaces, etc. and are not expected to follow a given ABI.
(They *could*, but in that case they would simply take the lead from DEC, on
whom they are dependent anyway because of the hardware. Effectively, DEC as
source of the processor becomes a clearinghouse for OS work and defines a
de facto ABI.) And I strongly doubt that Stallman would let a little thing
like an ABI get into his way....
Thus, for DEC to register an ABI would be pointless, and if so doing would
create work for AT&T that would have no effect on portability then AT&T has
no reason to accept a VAX ABI.
--
Brandon S. Allbery | "Given its constituency, the only
uunet!marque,sun!mandrill}!ncoast!allbery | thing I expect to be "open" about
Delphi: ALLBERY MCI Mail: BALLBERY | [the Open Software Foundation] is
comp.sources.misc: ncoast!sources-misc | its mouth." --John Gilmore
-----------------------------
From: "Brandon S. Allbery" <allbery@ncoast.uucp>
Subject: Re: What do panic messages mean?
Date: 26 Jun 88 16:20:45 GMT
Followup-To: comp.unix.xenix
To: unix-wizards@brl-sem.arpa
As quoted from <170@pigs.UUCP> by haugj@pigs.UUCP (The Beach Bum):
+---------------
| In article <446@sysco>, chapman@sco.COM (brian chapman) writes:
| ] In article <2375@rpp386.UUCP> jfh@rpp386.UUCP (The Beach Bum) writes:
| ] [ now, what i want to know is what is a DNA trap? does this mean the
| ] [ machine has been genetically mutated?
| ]
| ] DNA is Device Not Availible (floating point device, that is)
| ] Meaning the kernel is executing *87 instructions. Or trying to.
|
| its True Meaning(tm), how come i don't see it when i am executing
| 80387 instructions? i mean, i use floating point code, but never
+---------------
Here's how it works on the 386 boxes I've used:
The user-mode trap table is set up so that if an 80387 instruction is seen
and the 80387 is not installed, the instruction traps to an emulator.
However, there is no such arrangement in the kernel -- so if the kernel
tries to run an 80387 instruction and there's no 80387 chip the system panics.
This presumably is because the emulator can't easily be made to work in
kernel mode; also, the kernel shouldn't need to do floating point unless
some kind of special device driver is used -- in which case you probably
want the 80387 anyway, for speed. (The system'd get pretty slow if the
kernel were spending large amounts of its time in the emulator called from
kernel mode.)
--
Brandon S. Allbery | "Given its constituency, the only
uunet!marque,sun!mandrill}!ncoast!allbery | thing I expect to be "open" about
Delphi: ALLBERY MCI Mail: BALLBERY | [the Open Software Foundation] is
comp.sources.misc: ncoast!sources-misc | its mouth." --John Gilmore
-----------------------------
From: "Brandon S. Allbery" <allbery@ncoast.uucp>
Subject: Re: SVVS (was OSF discussion)
Date: 26 Jun 88 16:34:19 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@brl-sem.arpa
As quoted from <595@root44.co.uk> by aegl@root.co.uk (Tony Luck):
+---------------
| calls. SVVS (2.0 maybe 3.0) gives bogus arguments to system calls and
| checks that 'errno' is set to the 'correct' value. This can cause problems
| if your kernel doesn't check the arguments in the same order that an AT&T
| kernel does. E.g. what should be the error caused by this call to read(2)?
|
| close(0);
| read(0, (char *)NULL, -23);
|
| There are some tests in SVVS 2.0 that require certain error returns even
| though more than one seems possible.
+---------------
This sounds like a bug in SVVS or an incomplete SVID. Either case should be
fixed: either AT&T should define the argument checking in the SVID or they
should accept any of the error returns possible from the call.
Before you flame AT&T to death about this, remember that they're fairly new
to this kind of thing; it'll take some time to work the glitches out of both
SVID and SVVS, and the only way it'll get done is if you tell AT&T that the
glitches exist and give examples.
--
Brandon S. Allbery | "Given its constituency, the only
uunet!marque,sun!mandrill}!ncoast!allbery | thing I expect to be "open" about
Delphi: ALLBERY MCI Mail: BALLBERY | [the Open Software Foundation] is
comp.sources.misc: ncoast!sources-misc | its mouth." --John Gilmore
-----------------------------
From: Doug Gwyn <gwyn@brl-smoke.arpa>
Subject: Re: Why DEC doesn't need an ABI
Date: 26 Jun 88 20:05:45 GMT
To: unix-wizards@SEM.BRL.MIL
In article <8185@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes:
>Thus, for DEC to register an ABI would be pointless, and if so doing would
>create work for AT&T that would have no effect on portability then AT&T has
>no reason to accept a VAX ABI.
It's not at all pointless! The lack of COFF support on VAX 4BSD has
caused me vast amounts of otherwise unnecessary extra work. Also, we
have sometimes acquired libraries (e.g. for DBMS systems) from third-
party vendors, but since they've been for native 4BSD, they haven't
been usable with our applications that are developed in the System V
(emulated) environment running on 4BSD, even though I went through
the trouble of adapting our System V environment to use 4BSD object
formats so that the library is at least linkable (that's not enough
to guarantee that it works right).
Based on such experience, I would say that a good object or binary
standard would be of considerable practical value.
Perhaps DEC tried to register a COFF- or SVID-incompatible format as
part of the VAX ABI? That would be good grounds for AT&T rejecting it.
-----------------------------
From: Jacob Gore <gore@eecs.nwu.edu>
Subject: Re: wasting VM: the Sun philosophy (was Re: grep replacement)
Date: 26 Jun 88 20:09:08 GMT
To: unix-wizards@SEM.BRL.MIL
/ comp.unix.wizards / mouse@mcgill-vision.UUCP (der Mouse) / Jun 26, 1988 /
In article <8167@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon S. Allbery) writes:
>... the /dev/stdin point was first brought up as follows:
>
>> 22) support a filename of - to mean standard input.
>> a unix without /dev/stdin is largely bogus but as a sop to the poor
>> barstards having to work on BSD, gre will support -
>> as stdin (at least for a while).
Well, if it's going to support "-" anyway:
ln -s - /dev/stdin
:-)
Jacob
-----------------------------
From: "Daniel R. Levy" <levy@ttrdc.uucp>
Subject: RTFM on sendmail (was Re: C Finite Elements?)
Date: 26 Jun 88 23:56:58 GMT
To: unix-wizards@SEM.BRL.MIL
In article <1330@swlabs.UUCP>, jack@swlabs.UUCP (Jack Bonn) writes:
# In article <16278@brl-adm.ARPA> rbj@cmr.icst.nbs.gov (Root Boy Jim) writes:
# > Methinks you'll be looking at a
# >file named /usr/lib/sendmail.cf soon. Have fun, we all do :-)
# Just where does one go to read all the intricacies of sendmail
# configuration? Please: I'll RTFM if you tell me WITFM (Where is
# the ...).
# Does one of the Nutshell guides cover this (having heard good things
# about them)?
"Me Too!" I wonder if it's like Emacs, i.e., "if you have to read a stinking
manual, you're not wizardly enough to use it yet :-)".
--
|------------Dan Levy------------| THE OPINIONS EXPRESSED HEREIN ARE MINE ONLY
| AT&T Data Systems Group | AND ARE NOT TO BE IMPUTED TO AT&T.
| Skokie, Illinois |
|-----Path: att!ttbcad!levy-----|
-----------------------------
End of UNIX-WIZARDS Digest
**************************